Un intéressant article vient de paraitre sur lemondeinformatique.fr : une enquête de la NSA recense le top 25 des erreurs de programmation.
- l'article cité;
- La page où on peut voir cette liste [en]

Très instructif

Je me risque à une traduction pour que tout le monde en profite, car c'est intéressant

Les 25 catégories d'erreurs de programmation les plus dangereuses sont organisées en trois grandes classes :

Communication non sécurisée entre composants

Ces faiblesses regroupent les différentes manières dont les données sont émises/reçues entre composants, modules, programmes, process, threads, ou systèmes.

* CWE-20: Validation insuffisante des entrées
* CWE-116: Filtrage/formatage ou échappement insuffisant des sorties
* CWE-89: Défauts de protection des requêtes SQL (aka 'SQL Injection')
* CWE-79: Défauts de protection de la structure de la page web (aka 'Cross-site Scripting')
* CWE-78: Défauts de protection des commandes système éxécutées (aka 'OS Command Injection')
* CWE-319: Transmission en clair d'informations sensibles
* CWE-352: Cross-Site Request Forgery (CSRF)
* CWE-362: Race Condition
* CWE-209: Fuite d'informations à travers les messages d'erreur

Prise de risque dans la gestion des ressources

Ces faiblesses couvrent les cas où le logiciel ne gère pas convenablement l'allocation, l'utilisation, le déplacement ou la destruction des ressources systèmes.

* CWE-119: Défaut de maîtrise de l'empreinte mémoire du programme.
* CWE-642: Externalisation du contrôle de données critiques
* CWE-73: Externalisation du contrôle de noms de fichiers/chemins
* CWE-426: Autorisation d'accès dans des emplacements hasardeux
* CWE-94: Défaut de perméabilité dans le code généré (aka 'Code Injection')
* CWE-494: Téléchargement de code éxécutable sans contrôle d'intégrité
* CWE-404: Défaut de libération des ressources allouées
* CWE-665: Initialisation incorrecte
* CWE-682: Calcul incorrect

Failles défensives

Ces faiblesses regroupent les cas où un mécanisme défensif essentiel est mal utilisé, détourné ou tout simplement ignoré.

* CWE-285: Défaut de contrôle d'accès (Authorization)
* CWE-327: Usage d'un mécanisme de chiffrement risqué ou compromis (ex : MD5)
* CWE-259: Mot de passe "en dur"
* CWE-732: Octroi de permission non sécurisée sur une partie-clé du programme
* CWE-330: Usage de valeurs aléatoires pas assez aléatoires.
* CWE-250: Usage de permissions supérieures au strict nécessaire.
* CWE-602: Réalisation côté client de mécanismes de sécurité essentiels au serveur

Hey ,

Clairement, ils ont pris une application non testée et ils ont relevé les erreurs … non ?

yop,
Je me pose un question concernant l'item CWE-327, mais surtout son exemple...
Depuis que le monde est... Non en fait depuis que je dévellope , j'ai toujours lu (ici et ailleurs) que des données hashées était toujours plus sécurisées au cas où il y aurait un accès à la base par exemple...
Alors qu'est-ce qui pèche içi? md5() en lui même? du coup on remplace par exemple par sha1() ?
Ou est-ce en général le hashage des données sensibles?

merci

Je suis un peu obligé de te répondre vu que j'ai moi-même ajouté cet exemple.

Le problème est que le chiffrement MD5 a été cracké. Ca veut dire par exemple qu'on sait générer deux clés md5 identiques pour deux contenus différents (collision) ou bien encore retrouver un mot de passe d'après une clé md5 (brute-forcing). En d'autres termes, du point de vue de la sécurité informatique, MD5 a perdu tout son intérêt et il faut à présent préférer SHA-1, AES ou autres pour tout nouveau développement ou la sécurité est un point sensible.

Le md5 est "compromis" pour plusieurs raisons :
- Cryptographiquement parlant, des failles ont été découvertes dans l'algorithme, mais personne n'a encore réussi à les exploiter.
- D'une manière plus pragmatique, il existe des bases de données de hash md5 sur internet, et il est beaucoup plus rapide, lorsqu'on a sous la main le hash, d'interroger ces bases. Donc dans le cas où le mot de passe est relativement simple, il y a des chances non négligeables d'être dans une de ces bases.

Si on ignore la faille cryptographique, le md5 n'est pas mauvais en soi, il faut juste utiliser un grain avec pour rendre totalement inopérants les dictionnaires de mot de passe que j'ai évoqués.

Je pondérerais que si on veut simplement obtenir une chaîne unique pour un identifiant de fichier ou un truc du genre, MD5 est tout à fait approprié. Par contre, quand il est question de mot de passe ou de données sensibles de ce genre, il faut regarder les autres cryptages disponibles sur notre plate-forme .

Ok, donc c'est pas le principe de hashage qui est remmis en question...
AES, kesako? j'ai regardé un peu partout, c'est un chiffrement symétrique... non? est-ce bien sage de s'en servir?

Bon allez j'arrête de polluer le sujet, quoique:

HS: il serait bon de faire un tutoriel, rappelant quels sont les principes à adopter pour sécuriser une application
(genre, escape sql, doubler javascript par php, hashage des mots de passes, vol de sessions.. etc)

...
AES, kesako?...

C'est un algorythme de chiffrement, implémenté entre autres dans MySQL dans les fonctions AES_ENCRYPT et AES_DECRYPT(), chiffrement réversible.

Si tu vas sur le site de PHPFrance, il y a un tuto sur le chiffrement

...le md5 n'est pas mauvais en soi, il faut juste utiliser un grain avec pour rendre totalement inopérants les dictionnaires de mot de passe que j'ai évoqués.

Comme le souligne Calimero avec à propos : on peut parfaitement résoudre ce soucis et continuer à utiliser md5() mais en utilisant un paramètre supplémentaire, le "grain de sel" qui va ruiner les efforts de bien des pirates même bardés de dictionnaires de hack.

Je suis pour les bonnes pratiques, mais j'ai vu en prod des applis dont les mots de passe n'étaient même pas chiffrés, alors MD5() vaut toujours mieux que rien, hein

On veut des noms .
Cyrano pourrait aussi nous en donner hélas .

C'est quoi cette bataille d'arrière garde des Viphp autour du md5 ? Bien entendu qu'avec un grain de sable c'est suffisamment sécurisé mais on peut mettre aussi son grain de sable avec du SHA-1.

Effectivement pour des raisons de compatibilité avec d'anciens scripts ou bdd on peut continuer à utiliser le md5 sans problème, mais il serait bon de conseiller, en dehors de ce cas, d'utiliser le SHA-1 pour tout nouveau script.

Le SHA-1 a été conçu pour améliorer les performances du md5, alors pourquoi s'en priver ?

D'autant qu'il existe des class javascript SHA-1 (pour pouvoir par exemple hasher son grain de sel concaténé au mdp/login avant l'envoi du post) qui sont parfaitement fonctionnelles.

Alors faudrait être clair, le md5 oui si besoin de compatibilité ascendante, sinon SHA-1 minimum.

Pardonnez mon ignorance crasse en matière de cryptage,
mais...

on doit dire "grain de sel" ou "grain de sable" ?



C'est pour savoir si je dois recoder toute mon appli...

pour moi grain de sel…