Question Que devrait savoir chaque programmeur sur la sécurité? [fermé]


Je suis un étudiant en informatique et je suis maintenant en troisième année à l'université. Jusqu'à présent, nous avons étudié de nombreux sujets liés aux ordinateurs en général (programmation, algorithmes, architecture informatique, mathématiques, etc.).

Je suis très sûr que personne ne peut tout apprendre sur la sécurité, mais il est certain qu'il y a un minimum de connaissances que tout programmeur ou étudiant en informatique devrait connaître et ma question est: quelles sont ces connaissances minimales?

Pouvez-vous suggérer des livres électroniques ou des cours ou quoi que ce soit qui puisse vous aider à démarrer sur cette route?


411


origine


Réponses:


Principes à retenir si vous souhaitez que vos applications soient sécurisées:

  • Ne faites confiance à aucune contribution! 
  • Valider l'entrée  de toutes les sources non fiables - utiliser les listes blanches et non les listes noires
  • Prévoyez la sécurité dès le début - ce n'est pas quelque chose que vous pouvez visser à la fin
  • Restez simple - la complexité augmente les risques de failles de sécurité
  • Garder votre surface d'attaque au minimum
  • Assurez-vous échouer en toute sécurité
  • Utilisation défense en profondeur
  • Adhérer au principe de le moindre privilège 
  • Utilisation modélisation des menaces
  • Compartimenter - donc votre système n'est pas tout ou rien
  • Cacher des secrets est difficile - et les secrets cachés dans le code ne resteront pas secrets longtemps
  • N'écrivez pas votre propre crypto
  • Utiliser crypto ne signifie pas que vous êtes en sécurité (les attaquants chercheront un lien plus faible)
  • Soyez conscient de débordement de tampon et comment se protéger contre eux

Il existe d'excellents livres et articles en ligne sur la sécurisation de vos applications:

Former vos développeurs sur les meilleures pratiques de sécurité applicative 

Codebashing (payé)

Innovation de sécurité(payé)

Boussole de sécurité (payé)

OWASP WebGoat (gratuit)


536



Règle n ° 1 de la sécurité pour les programmeurs: Ne roulez pas vous-même

Sauf si vous êtes vous-même un expert en sécurité et / ou un cryptographe, toujours utilisez une plate-forme, un cadre ou une bibliothèque de sécurité bien conçue, bien testée et mature pour faire le travail pour vous. Ces choses ont passé des années à être réfléchies, corrigées, mises à jour et examinées par des experts et des hackers. Vous voulez obtenir ces avantages, ne pas les rejeter en essayant de réinventer la roue.

Maintenant, cela ne veut pas dire que vous n'avez pas besoin d'apprendre quoi que ce soit sur la sécurité. Vous devez certainement en savoir assez pour comprendre ce que vous faites et vous assurer que vous utilisez les outils correctement. Cependant, si vous vous trouvez sur le point de commencer à écrire votre propre algorithme de cryptographie, votre système d'authentification, votre désinfectant d'entrée, etc., arrêtez, prenez du recul et n'oubliez pas la règle n ° 1.


100



Chaque programmeur doit savoir comment écrire du code d'exploitation.

Sans savoir comment les systèmes sont exploités, vous bloquez accidentellement les vulnérabilités. Savoir réparer un code n'a absolument aucun sens si vous ne savez pas comment tester vos correctifs. La sécurité ne se résume pas à un tas d’expériences de réflexion, vous devez être scientifique et tester vos expériences.


67



La sécurité est un processus, pas un produit.

Beaucoup semblent oublier cette évidence.


39



Je suggère de revoir CWE / SANS TOP 25 Erreurs de programmation les plus dangereuses. Il a été mis à jour pour 2010 avec la promesse de mises à jour régulières à l'avenir. le 2009 la révision est également disponible.

De http://cwe.mitre.org/top25/index.html

Les 25 erreurs de programmation les plus dangereuses de CWE / SANS 2010 sont une liste des erreurs de programmation les plus répandues et les plus critiques qui peuvent mener à des vulnérabilités logicielles sérieuses. Ils sont souvent faciles à trouver et faciles à exploiter. Ils sont dangereux car ils permettent fréquemment à des attaquants de reprendre complètement le logiciel, de voler des données ou d'empêcher le logiciel de fonctionner.

La liste Top 25 est un outil d'éducation et de sensibilisation pour aider les programmeurs à prévenir les types de vulnérabilités qui affligent l'industrie du logiciel, en identifiant et en évitant les erreurs trop courantes qui se produisent avant même que le logiciel ne soit livré. Les clients du logiciel peuvent utiliser la même liste pour les aider à demander un logiciel plus sécurisé. Les chercheurs en sécurité logicielle peuvent utiliser le Top 25 pour se concentrer sur un sous-ensemble étroit mais important de toutes les faiblesses de sécurité connues. Enfin, les responsables logiciels et les responsables informatiques peuvent utiliser la liste Top 25 comme mesure de progrès dans la sécurisation de leurs logiciels.


22



Un bon cours de démarrage pourrait être le cours de MIT en Réseaux informatiques et sécurité. Une chose que je suggère est de ne pas oublier la vie privée. La confidentialité, dans certains sens, est vraiment fondamentale pour la sécurité et n'est pas souvent couverte par des cours techniques sur la sécurité. Vous pourriez trouver du matériel sur la vie privée dans ce cours sur Éthique et droit en ce qui concerne Internet.


12



L’équipe Web Security de Mozilla a mis au point un excellent guide, que nous respectons dans le développement de nos sites et services.


9



L'importance des valeurs par défaut sécurisées dans les frameworks et les API:

  • Beaucoup de premiers frameworks web n'ont pas échappé html par défaut dans les templates et ont eu des problèmes XSS à cause de ça
  • Beaucoup de premiers frameworks Web facilitaient la concaténation de SQL plutôt que la création de requêtes paramétrées conduisant à de nombreux bogues d’injection SQL.
  • Certaines versions d'Erlang (R13B, peut-être d'autres) ne vérifient pas les certificats pairs SSL par défaut et il y a probablement beaucoup de code erlang qui est sensible aux attaques SSL MITM
  • Le transformateur XSLT de Java par défaut permet l'exécution de code java arbitraire. Il y a eu beaucoup de bogues de sécurité graves créés par ceci.
  • Les API d'analyse syntaxique XML de Java permettent par défaut au document analysé de lire des fichiers arbitraires sur le système de fichiers. Plus amusant :)

6



Vous devriez savoir à propos des trois A Authentification, autorisation, audit. Erreur classique est d'authentifier un utilisateur, tout en ne vérifiant pas si l'utilisateur est autorisé à effectuer une action, de sorte qu'un utilisateur peut regarder d'autres photos privées des utilisateurs, l'erreur Diaspora fait. Beaucoup, beaucoup plus de gens oublient Audit, vous devez, dans un système sécurisé, être capable de dire qui a fait quoi et quand.


5



  • Rappelez-vous que vous (le programmeur) devez sécuriser toutes les parties, mais l'attaquant doit seulement réussir à trouver un pli dans votre armure.
  • La sécurité est un exemple "d'inconnues inconnues". Parfois, vous ne saurez pas quelles sont les failles de sécurité possibles (jusqu’à après).
  • La différence entre un bug et un trou de sécurité dépend de l'intelligence de l'attaquant.

4