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

427

Je suis étudiant en informatique et je suis actuellement en 3è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 y a une connaissance "minimale" que chaque programmeur ou étudiant en informatique devrait connaître et ma question est quelle est cette connaissance minimale?

Pouvez-vous suggérer des livres électroniques ou des cours ou quoi que ce soit peut vous aider à commencer avec cette route?

security 
— MH
source
6
— Thomas
118
Règle n ° 1: ne faites jamais confiance à l'entrée de l'utilisateur. Pas même si c'est ta grand
— Anthony Forloney
2
..et ce fil a également la grande information - stackoverflow.com/questions/72394/…
— Sripathi Krishnan
ma question ne concerne pas seulement les programmeurs et leurs erreurs, mais aussi les étudiants en informatique et en informatique
— Mohamad Alhamoud
1
Regardez vos messages d'erreur. Bien que vous souhaitiez être convivial, la différence entre «Ce compte n'existe pas» et «Le mot de passe n'est pas valide» peut être dangereuse dans certains cas.
— Michael Mior

Réponses:

551

Principes à garder à l'esprit si vous souhaitez que vos applications soient sécurisées:

  • Ne faites jamais confiance à aucune entrée!
  • Valider les entrées de toutes les sources non fiables - utiliser des listes blanches et non des listes noires
  • Planifiez la sécurité dès le début - ce n'est pas quelque chose que vous pouvez verrouiller à la fin
  • Restez simple - la complexité augmente la probabilité de failles de sécurité
  • Gardez votre surface d'attaque au minimum
  • Assurez-vous que vous échouez en toute sécurité
  • Utilisez la défense en profondeur
  • Adhérer au principe du moindre privilège
  • Utiliser la modélisation des menaces
  • Compartimenter - pour que votre système ne soit 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
  • L'utilisation de la cryptographie ne signifie pas que vous êtes en sécurité (les attaquants chercheront un lien plus faible)
  • Soyez conscient des débordements de tampon et comment vous protéger contre eux

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

Formez vos développeurs aux meilleures pratiques de sécurité des applications

Codebashing (payant)

Innovation en sécurité (payant)

Boussole de sécurité (payante)

OWASP WebGoat (gratuit)

— bignum
source
+1 "Exploiter un logiciel: comment briser le code" est un excellent livre, mais ce diaporama auquel vous êtes lié est horrible.
— tour
7
Cependant, malheureusement, il est presque impossible d'instancier le principe du moindre privilège dans tout système moderne. Par exemple, le noyau Linux (source que j'utilise actuellement) contient plus de 9,4 millions de lignes de code C et plus de 400 000 lignes d'assemblage, qui s'exécutent toutes dans un contexte sans restriction. Une simple erreur de calcul (peut-être intentionnelle) dans l'une de ces millions de lignes compromettra l'ensemble du système. Peut-être qu'au cours du prochain siècle ou deux, une solution émergera, peut-être pas, car personne ne se soucie réellement de créer des systèmes d'exploitation / langages / cadres sécurisés.
— L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
1
J'ajouterais «Le manuel du pirate d'applications Web» à cette liste.
— dépassé
34
Remplacez "Ne faites jamais confiance à l'entrée de l'utilisateur!" à "Ne faites confiance à aucune entrée!". Les entrées provenant d'autres logiciels doivent être traitées de la même manière que les entrées utilisateur - par exemple, dans la journalisation de sites Web, la plupart des gens ne penseraient pas que le champ ID utilisateur-agent / navigateur est une «entrée utilisateur», mais il peut tout aussi facilement contenir, par exemple, un Injection SQL.
— Peteris
2
@ L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Eh bien, il y a ce système d'exploitation expérimental de Microsoft Research (Singularity) basé sur .NET, qui visait la sécurité comme objectif principal (pas de débordements de tampon, yay!). Pas de partage de mémoire de processus, pas d'auto-modification de code, même les pilotes de périphériques ne sont qu'un autre processus isolé par logiciel dans .NET. Un concept assez intéressant, mais il serait très difficile de le proposer aux gens (surtout, il ne peut pratiquement pas faire de compatibilité descendante avec les logiciels existants ou même les pilotes; un peu comme les 10 premières années de Linux: D).
— Luaan
102

Règle n ° 1 de sécurité pour les programmeurs: ne lancez pas la vôtre

À moins que vous ne soyez vous-même un expert en sécurité et / ou un cryptographe, utilisez toujours une plateforme, une infrastructure 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 pensées, corrigées, mises à jour et examinées par des experts et des pirates. Vous voulez gagner ces avantages, pas les écarter 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. Cependant, si vous vous trouvez sur le point de commencer à écrire votre propre algorithme de cryptographie, système d'authentification, désinfectant d'entrée, etc., arrêtez-vous, reculez et souvenez-vous de la règle n ° 1.

— Tyler McHenry
source
10
C'est une mauvaise règle à mon avis. Vous pouvez essentiellement être ciblé uniquement en raison de la plate-forme que vous sélectionnez, plutôt que d'un véritable intérêt pour vos actifs. Pensez à tous les trous de sécurité qui se trouvent dans les plateformes tierces et à tous les produits qui sont instantanément vulnérables juste parce qu'ils l'utilisent. Je ne serais pas si rapide à confier ma sécurité à un tiers.
— Fosco
9
Je pense que c'est une bonne règle pour Crypto - rouler votre propre cryptage est une recette pour un désastre. Mais faire rouler votre propre moteur de blog peut être plus sûr, comme le souligne Fosco - si vous lancez le vôtre, vous êtes moins susceptible d'être pris par des attaques automatisées auxquelles les installations de wordpress doivent faire face.
— James P McGrath
5
En ce qui concerne la cryptographie, cette règle est absolument correcte. N'écrivez pas votre propre crypto, point final. Quand il s'agit d'utiliser des plateformes tierces, cela dépend. Certaines plates-formes sont intrinsèquement plus sécurisées, certaines plates-formes sont intrinsèquement moins sécurisées, et la plupart des plates-formes fournissent probablement certaines fonctionnalités de sécurité, mais aussi certains vecteurs d'attaque connus. Prenez la récente vulnérabilité Rails qui a provoqué une faille de sécurité sur github . Sans aucun doute, Rails offre de nombreuses fonctionnalités de sécurité, mais il possède également des fonctionnalités puissantes avec des valeurs par défaut non sécurisées.
— Michael Kopinsky
7
En ce qui concerne la cryptographie, ne lancez pas la vôtre - mais comprenez ce que vous utilisez. Si vous ne comprenez pas pourquoi l'utilisation de la même clé de chiffrement pour RC4 pour deux messages est une idée horrible, lisez avant d'utiliser un chiffrement de flux, par exemple.
— Christopher Creutzig
3
Même après le bug HeartBleed, il est évident que c'est une bonne règle. Imaginez à quel point il aurait été difficile de trouver un bogue semblable à un saignement dans un projet personnalisé ou propriétaire. Si vous lancez le vôtre, vous vous cachez juste derrière l'obscurité et vous ne saurez pas quels bogues pourraient être exploités.
— Sqeaky
71

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

Sans savoir comment les systèmes sont exploités, vous arrêtez accidentellement des vulnérabilités. Savoir comment patcher du code n'a absolument aucun sens sauf si vous savez comment tester vos patches. La sécurité n'est pas seulement un tas d'expériences de pensée, vous devez être scientifique et tester vos expériences.

— tour
source
10
Je dirais que ce n'est pas nécessaire du tout. Adhérez simplement au principe: si l'attaquant peut provoquer une corruption de mémoire de quelque nature que ce soit, considérez-vous comme appartenant. Pas besoin d'entrer dans les détails de l'écriture (de travail) des exploits.
— newgre
6
@newgre toutes les vulnérabilités ne sont pas un débordement de tampon. Il existe quelques milliers de vulnérabilités couvertes par le système d'énumération des faiblesses communes. Un programmeur doit comprendre l'esprit de l'attaquant, sans quoi il ignorera commettre des erreurs.
— tour
1
Je sais que tous ne sont pas un débordement de tampon, mais tout ce qui est généralement appelé "exploit" est basé sur une sorte de corruption de mémoire: débordements de tampon, doubles libérations, débordements de tas, débordements liés à des entiers, chaînes de formatage , etc. Bien sûr, il y a d'autres choses comme les bogues logiques, mais ce n'était pas le sujet de cette réponse pour commencer.
— newgre
5
@newgre C'est un type d'exploit, mais aujourd'hui, plus d'exploits sont écrits pour exploiter les failles des applications Web que les problèmes de corruption de mémoire. Les exploits sont écrits en utilisant SQL Injection, Local File include, CSRF et XSS, ce sont les problèmes courants. (Source: exploit-db.com )
— tour
1
Je suis d'accord, si vous pouvez vous-même écrire des exploits, vous pouvez comprendre ce qui peut aller à l'esprit des pirates au maximum!
— linuxeasy
42

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

Beaucoup semblent oublier cette question de fait évidente.

— ericteubert
source
23

Je suggère de revoir CWE / SANS TOP 25 des 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.

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

Le Top 25 des erreurs de programmation CWE / SANS 2010 les plus dangereuses est 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 à 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 expédié. Les clients des 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 gestionnaires de logiciels et les DSI peuvent utiliser la liste Top 25 comme un indicateur de progrès dans leurs efforts pour sécuriser leurs logiciels.

— jschmier
source
1
Notez que les 4 principales erreurs de cette liste (et un tas d'autres également) sont toutes les mêmes erreurs - confiance en entrée.
— Chris Dodd
13

Un bon cours de démarrage pourrait être le cours du MIT sur les réseaux informatiques et la sécurité . Une chose que je suggérerais est de ne pas oublier la vie privée. À certains égards, la confidentialité est vraiment fondamentale pour la sécurité et n'est pas souvent abordée dans les cours techniques sur la sécurité. Vous trouverez peut-être des informations sur la vie privée dans ce cours sur l' éthique et le droit en ce qui concerne Internet.

— tvanfosson
source
Le lien du cours MIT ne fonctionne pas
— AntonioCS
1
Liens corrigés (pour l'instant). Merci.
— tvanfosson
10

L'équipe de sécurité Web de Mozilla a élaboré un excellent guide que nous respectons dans le développement de nos sites et services.

— Potch
source
8

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

  • Beaucoup de frameworks Web antérieurs n'échappaient pas au HTML par défaut dans les modèles et avaient des problèmes XSS à cause de cela
  • De nombreux frameworks Web antérieurs ont facilité 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 homologues SSL par défaut et il y a probablement beaucoup de code Erlang susceptible aux attaques SSL MITM
  • Le transformateur XSLT de Java permet par défaut l'exécution de code java arbitraire. Il y a eu de nombreux bogues de sécurité graves créés par cela.
  • Les API d'analyse XML de Java par défaut permettent au document analysé de lire des fichiers arbitraires sur le système de fichiers. Plus amusant :)
— benmmurphy
source
5

Vous devriez connaître les trois A. Authentification, autorisation, audit. L'erreur classique consiste à authentifier un utilisateur, tout en ne vérifiant pas si l'utilisateur est autorisé à effectuer une action, de sorte qu'un utilisateur peut regarder les photos privées d'autres utilisateurs, comme l'a fait l'erreur Diaspora. Beaucoup, beaucoup plus de gens oublient Audit, vous avez besoin, dans un système sécurisé, de pouvoir dire qui a fait quoi et quand.

— rapadura
source
1
Toutes les autorisations ne nécessitent pas d'authentification. "From ABAC to ZBAC" contraste le contrôle d'accès NBAC (basé sur l'authentification) avec des solutions qui ne nécessitent pas d'authentification. "IBAC, RBAC, ABAC et même CBAC - Le contrôle d'accès basé sur les revendications repose tous sur l'authentification ... Pour plus de simplicité, ce document les traite comme une solution unique et ignore les versions qui ont implémenté certains aspects de l'architecture ZBAC. Elles sont collectivement appelées authentification Contrôle d'accès basé (NBAC). "
— Mike Samuel
4
  • N'oubliez pas que vous (le programmeur) devez sécuriser toutes les pièces, mais l'attaquant n'a qu'à réussir à trouver un pli dans votre armure.
  • La sécurité est un exemple des "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.
— Rory
source
4

J'ajouterais ce qui suit:

  • Fonctionnement des signatures numériques et des certificats numériques
  • Qu'est-ce que le sandbox

Comprendre le fonctionnement des différents vecteurs d'attaque:

  • Débordements de tampon / débordements / etc sur le code natif
  • Engineering social
  • Usurpation DNS
  • L'homme au milieu
  • CSRF / XSS et al
  • Injection SQL
  • Attaques cryptographiques (ex: exploiter des algorithmes cryptographiques faibles tels que DES)
  • Erreurs de programme / framework (ex: dernière faille de sécurité de github )

Vous pouvez facilement google pour tout cela. Cela vous donnera une bonne base. Si vous souhaitez 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.

— Miguel Ping
source
4

lorsque vous construisez une entreprise ou l'un de vos propres logiciels, vous devriez simplement penser comme un pirate informatique. Comme nous savons que les pirates informatiques ne sont pas non plus experts en toutes choses, mais quand ils trouvent une vulnérabilité, ils commencent à creuser en collectant des informations sur tous les choses et enfin attaquer notre logiciel.Pour empêcher de telles attaques, nous devons suivre certaines règles bien connues comme:

  • essayez toujours de casser vos codes (utilisez des 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'utilisateur ou d'entrées automatisées.
  • utiliser des applications open source (leurs failles de sécurité les plus connues sont connues et résolues).

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

pour plus d'informations, google sur les flux de sécurité de votre fournisseur d'applications.

— rahul_pratap
source
3
  1. Pourquoi est important.
  2. Il s'agit de compromis.
  3. La cryptographie est en grande partie une distraction de la sécurité.
— Richard
source
3

Pour des informations générales sur la sécurité, je recommande fortement de lire Bruce Schneier . Il a un site Web, sa newsletter crypto-gramme , plusieurs livres et a fait beaucoup d' interviews .

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

Pour un bon livre (et assez divertissant) sur la façon dont la sécurité se déroule dans le monde réel, je recommanderais l'excellent (bien qu'un peu daté) 'The Cuckoo's Egg' de Cliff Stoll.

— Dan Esparza
source
3

Assurez-vous également de consulter la liste des 10 meilleurs OWASP pour une catégorisation de tous les principaux vecteurs / vulnérabilités d'attaque.

Ces choses sont fascinantes à lire. Apprendre à penser comme un attaquant vous apprendra à quoi penser lorsque vous écrivez votre propre code.

— Michael Kopinsky
source
2

Salez et hachez les mots de passe de vos utilisateurs. Ne les enregistrez jamais en texte brut dans votre base de données.

— Abdull
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.