Soyons réaliste, la plupart des vulnérabilités que ce soit les projets WEB ou autres applications sont des vecteurs connus et très bien documentés. La communication entre communautés de la sécurité et des programmeurs était certes pauvre mais ce n'est plus le cas [1].
Si les règles de base étaient appliquées, on verrait une diminution notable de vulnérabilités présentes dans les logiciels. On va prendre le cas *simple* et récurrent des XSS/SQL injections dans les applications web, les filtrages sont souvent soit inexistants et reposent sur le framework parent (ASP/IIS mod_security etc), soit souvent basés sur des blacklists. Prenons l'exemple suivant: http://host/script?id=1
Il est facile de vérifier que "id" est un entier strict compris entre 0-65535 (whitelist). Pourquoi la plupart des programmateurs n'enlèvent juste que les ' " < > sur un *string* (blacklist) ?
On est d'accord c'est la partie la moins plaisante de la programmation avec la documentation, on reçoit beaucoup moins d'échos quand l'application est simple mais sécurisée que bugguée avec plein de fonctions.
Côté protocoles, il faut essayer de prendre un peu de recul et regarder les vulnérabilités des autres protocoles similaires [2]. Il est vrai que la fonctionnalité gagne souvent sur la stabilité. Certains protocoles comme les URL souffrent d'une RFC trop laxiste tel que le double encodage pour le HTTP toujours autorisé ou bien la fragmentation IP [3].
Ne JAMAIS supposer qu'une variable d'entrée est sécurisée (trusted) qu'elle vienne de la base de données, ou d'un DNS [4] ou voire même d'un whois [5].
En appliquant ces règles simples, le temps passé à la correction des bugs est souvent nettement inférieur (j'ai lu un article récemment sur ce point mais je ne retrouve plus le lien)
[^] # Re: Pratiques d'une ère (dé)passée
Posté par ~ lilliput . En réponse à la dépêche Threat modeling - Savez vous quelles sont les menaces qui guettent votre application ?. Évalué à 4.
Soyons réaliste, la plupart des vulnérabilités que ce soit les projets WEB ou autres applications sont des vecteurs connus et très bien documentés. La communication entre communautés de la sécurité et des programmeurs était certes pauvre mais ce n'est plus le cas [1].
Si les règles de base étaient appliquées, on verrait une diminution notable de vulnérabilités présentes dans les logiciels. On va prendre le cas *simple* et récurrent des XSS/SQL injections dans les applications web, les filtrages sont souvent soit inexistants et reposent sur le framework parent (ASP/IIS mod_security etc), soit souvent basés sur des blacklists. Prenons l'exemple suivant:
http://host/script?id=1
Il est facile de vérifier que "id" est un entier strict compris entre 0-65535 (whitelist). Pourquoi la plupart des programmateurs n'enlèvent juste que les ' " < > sur un *string* (blacklist) ?
On est d'accord c'est la partie la moins plaisante de la programmation avec la documentation, on reçoit beaucoup moins d'échos quand l'application est simple mais sécurisée que bugguée avec plein de fonctions.
Côté protocoles, il faut essayer de prendre un peu de recul et regarder les vulnérabilités des autres protocoles similaires [2]. Il est vrai que la fonctionnalité gagne souvent sur la stabilité. Certains protocoles comme les URL souffrent d'une RFC trop laxiste tel que le double encodage pour le HTTP toujours autorisé ou bien la fragmentation IP [3].
Ne JAMAIS supposer qu'une variable d'entrée est sécurisée (trusted) qu'elle vienne de la base de données, ou d'un DNS [4] ou voire même d'un whois [5].
En appliquant ces règles simples, le temps passé à la correction des bugs est souvent nettement inférieur (j'ai lu un article récemment sur ce point mais je ne retrouve plus le lien)
[1]: http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Projec(...)
[2]: (pub !) http://linuxfr.org/comments/1118391.html#1118391
[3]: http://www.symantec.com/connect/articles/evading-nids-revisi(...)
[4]: http://archives.neohapsis.com/archives/bugtraq/2001-10/0223.(...) , http://seclists.org/fulldisclosure/2004/Jun/438
[5]: http://ha.ckers.org/blog/20071230/xss-on-whois/
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk