Que doit savoir chaque programmeur en matière de sécurité?

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

• Ne faites confiance à aucune consortingbution!
• Valider les entrées de toutes les sources non fiables – utiliser les listes blanches et non les listes noires
• Planifier pour la sécurité dès le départ – ce n’est pas quelque chose que vous pouvez enfoncer à la fin
• Restez simple – la complexité augmente les risques de failles de sécurité
• Gardez votre surface d’attaque au minimum
• Assurez-vous que vous échouez en toute sécurité
• Utiliser la défense en profondeur
• Adhérer au principe du moindre privilège
• Utiliser la modélisation des menaces
• Compartimenter – votre système n’est pas tout ou rien
• Cacher des secrets est difficile – et les secrets cachés dans le code ne restront pas secrets longtemps
• N’écrivez pas votre propre crypto
• Utiliser crypto ne signifie pas que vous êtes en sécurité (les attaquants rechercheront un lien plus faible)
• Soyez conscient des dépassements de tampon et de la manière de les protéger

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

• Écrire Secure Code 2nd Edition – Je pense que chaque programmeur devrait lire ceci
• Création de logiciels sécurisés: Comment éviter les problèmes de sécurité dans le bon sens
• Livre de cuisine de programmation sécurisé
• Logiciel d’exploitation
• Ingénierie de la sécurité – une excellente lecture
• Programmation sécurisée pour Linux et Unix HOWTO

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

Codebashing (payé)

Sécurité Innovation (payant)

Boussole de sécurité (payant)

OWASP WebGoat (gratuit)

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

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

Maintenant, cela ne veut pas dire que vous n’avez rien à apprendre sur la sécurité. Vous devez certainement en savoir suffisamment pour comprendre ce que vous faites et vous assurer que vous utilisez correctement les outils. Toutefois, si vous êtes sur le sharepoint commencer à écrire votre propre algorithme de cryptographie, votre système d’authentification, votre assainisseur d’entrée, etc., arrêtez-vous, prenez du recul et mémorisez la règle n ° 1.

Chaque programmeur doit savoir écrire un 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é n’est pas juste un tas d’expériences de reflection, vous devez être scientifique et tester vos expériences.

La sécurité est un processus et non un produit.

Beaucoup semblent oublier cette évidence.

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. La révision de 2009 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 pouvant entraîner de graves vulnérabilités logicielles. 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 destiné à aider les programmeurs à prévenir les types de vulnérabilités qui frappent l’indussortinge du logiciel, en identifiant et en évitant les erreurs trop fréquentes qui surviennent avant même l’envoi du logiciel. Les clients logiciels peuvent utiliser la même liste pour les aider à demander des logiciels plus sécurisés. 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.

Un cours d’introduction en bonne et due forme pourrait être le cours de MIT sur les réseaux informatiques et la sécurité . Une chose que je suggère est de ne pas oublier la vie privée. La confidentialité, à certains égards, est vraiment fondamentale pour la sécurité et n’est pas souvent couverte par les cours techniques sur la sécurité. Vous pourriez trouver des documents sur la protection de la vie privée dans ce cours sur l’ éthique et le droit en ce qui concerne Internet.

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

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é au HTML par défaut dans les templates et ont eu des problèmes avec XSS à cause de cela.
• 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 certificates homologues SSL par défaut et il existe probablement beaucoup de code erlang susceptible d’être attaqué par MITM SSL
• 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’parsing syntaxique XML de Java permettent par défaut au document analysé de lire des fichiers arbitraires sur le système de fichiers. Plus amusant 🙂

Vous devriez connaître les trois A. Authentification, autorisation, audit. L’erreur classique est d’authentifier un utilisateur, sans vérifier si l’utilisateur est autorisé à effectuer certaines actions, afin qu’un utilisateur puisse regarder les photos privées d’autres utilisateurs, ce que l’erreur Diaspora a 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.

• Rappelez-vous que vous (le programmeur) devez sécuriser toutes les parties, mais l’attaquant ne doit réussir à trouver qu’un coup 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 une faille de sécurité dépend de l’intelligence de l’attaquant.

J’appendais ce qui suit:

• Comment fonctionnent les signatures numériques et les certificates numériques
• Qu’est-ce que le sandboxing

Comprendre comment fonctionnent les différents vecteurs d’attaque:

• Buffer déborde / sous-traite / etc sur le code natif
• Ingénierie sociale
• DNS spoofing
• L’homme au milieu
• CSRF / XSS et al
• Injection SQL
• Attaques Crypto (ex: exploitant des algorithmes cryptographiques faibles tels que DES)
• Erreurs de programme / cadre (ex: dernière faille de sécurité de github)

Vous pouvez facilement google pour tout cela. Cela vous donnera une bonne base. Si vous voulez voir les vulnérabilités des applications Web, il existe un projet appelé google gruyere qui vous montre comment exploiter une application Web qui fonctionne.

Lorsque vous construisez une entreprise ou un de vos logiciels, vous devez penser comme un pirate informatique. Nous soaps que les pirates informatiques ne sont pas non plus des experts dans ce domaine, mais quand ils découvrent une vulnérabilité, ils collectent des informations sur tous. les choses et enfin l’attaque sur notre logiciel.Afin de prévenir de telles attaques, nous devons suivre certaines règles bien connues comme:

• essayez toujours de casser vos codes (utilisez les cheatsheets et google les choses pour plus d’informations).
• être mis à jour pour les failles de sécurité dans votre domaine de programmation.
• et comme mentionné ci-dessus, ne faites jamais confiance à aucun type d’utilisateurs ou d’entrées automatisées.
• utiliser des applications opensource (leurs failles de sécurité les plus courantes sont connues et résolues).

vous pouvez trouver plus de ressources de sécurité sur les liens suivants:

• la sécurité
• CERT Sécurité
• SANS Sécurité
• netcraft
• Espace de sécurité
• Openwall
• PHP Sec
• thehackernews (continuez à vous mettre à jour)

Pour plus d’informations sur Google, consultez les stream de sécurité de votre fournisseur d’applications.

1. Pourquoi est-ce important?
2. Tout est question de compromis.
3. La cryptographie est en grande partie une distraction de la sécurité.

Pour des informations générales sur la sécurité, je recommande fortement de lire Bruce Schneier . Il a un site Web, son bulletin d’information sur le crypto-gramme , plusieurs livres et a fait de nombreuses interviews .

Je me familiariserais également avec l’ingénierie sociale (et Kevin Mitnick ).

Pour un bon livre (et plutôt divertissant) sur la manière dont la sécurité joue dans le monde réel, je recommanderais l’excellent “The Cuckoo’s Egg” de Cliff Stoll.

Veillez également à consulter la liste Top 10 OWASP pour une catégorisation de tous les principaux vecteurs d’attaques / vulnérabilités.

Ces choses sont fascinantes à lire. En apprenant à penser comme un attaquant, vous apprendrez à quoi penser lorsque vous écrivez votre propre code.

Salez et hachez les mots de passe de vos utilisateurs. Ne les enregistrez jamais en texte brut dans votre firebase database.

Je voulais juste partager ceci pour les développeurs web:

guide de sécurité pour les développeurs
https://github.com/FallibleInc/security-guide-for-developers