Sécurité des sites et applications Web : le problème est entre la chaise et le clavier, et ça ne s’améliore pas

Au début du l’essor du Web, il y a dix ans, il était courant que les problèmes de sécurité les plus graves viennent de bugs ou de failles présents dans les systèmes d’exploitation, les serveurs HTTP, les serveurs d’applications et autres composants “système”, ceux-là même sur lesquels les ingénieurs système, les DBA et les développeurs n’ont pas la main.

Avec le temps et la répétition de ces problèmes de sécurité, l’ensemble de éditeurs et des fournisseurs de ces couches basses a fait son travail et il est communément accepté aujourd’hui dans le monde de la sécurité et des hackers que les systèmes d’exploitation, serveurs HTTP et serveurs d’applications ont fortement gagné en robustesses et deviennent beaucoup plus difficiles à attaquer que par le passé.

On serait donc tentés de penser qu’avec maintenant 10 ans de recul et d’expérience accumulés sur le web, l’industrie et les écosystèmes du Web ont atteint une maturité qui confère aux sites et aux applications Web un niveau de sécurité confortable.

Pourtant, à y regarder de plus près, il semble bien justement qu’il n’en soit rien au niveau de certaines pratiques de codage dangereuses encore trop souvent utilisées par des développeurs. A croire que l’éducation en la matière ne porte pas ses fruits.

En Février 2004, je publiais ainsi un billet sur mon blog de l’époque (en Anglais) qui reflétait les résultats d’une enquête qui venait d’être publiée et dont les conclusions étaient que “seulement 10% des applications Web étaient protégées des techniques de hacking les plus courantes”. Si l’étude de la société WebCohort a depuis disparu, mon billet avait reproduit le tableau suivant :

Most Common Application Layer Vulnerabilities (Source: Webcohort)

Attack Percent vulnerable
Cross-site scripting 80%
SQL injection 62%
Parameter tampering 60%
Cookie poisoning 37%
Database server 33%
Web Server 23%
Buffer overflow 19%

 

En début de mois de Novembre 2009, donc cette année, et pratiquement cinq ans après l’étude suivante, une nouvelle étude publiée par Cenzic montre que la situation ne s’est pas améliorée, pire, elle se serait dégradée par rapport à 2008. Je cite :

“The number of software vulnerabilities detected has risen to the point that almost 9 out of 10 Web applications have flaws that could lead to the exposure of sensitive information.

Cenzic's "Web Application Security Trends Report Q1-Q2, 2009" report, released on Monday, says that more than 3,100 vulnerabilities were identified in the first half of the year, 10% more than the number identified in the second half of 2008.”

Si je lis bien “9 out of 10” ça fait donc 10% soit le même chiffre qu’en 2004.

En Février dernier, c’est l’ami Fred de Villamil qui se fait l’écho sur son blog du rapport annuel de CWE qui liste et explique le Top 25 des erreurs de sécurité dans les applications Web. Allez, on regarde vite fait le haute de la liste :

    1. Mauvais filtrage des données envoyées par les utilisateurs
    2. Mauvais encodage ou échappement des données en sortie
    3. Injections SQL
    4. Cross Site Scripting (ou XSS)
    5. Injection de commandes directement exécutables par le système d’exploitation (system() ou exec())
    6. CSRF
    7. Race conditions
    8. Divulgation d’informations dans les messages d’erreur (comme le PATH dans lequel est installée votre application web)

Comparez avec le tableau datant de 2004. Effarant, non ?

Plus récemment encore, c’est l’organisme OWASP (= Open Web Application Security Project) qui publie le très didactique rapport de ton Top10 des failles dans les applications Web, un véritable document de référence que chaque chef de projet ou team manager devrait passer une journée à lire et à travailler avec ses équipes de développement. Si j’étais encore chef de projet, c’est certain que j’aurais déjà conduit cette initiative avec mes équipes.

Rapport OWASP “The 10 Most Critical Web Application Security Risks, ed. 2010” – PDF, 21 pages

Vous pouvez le télécharger ici, l’imprimer, le distribuer à vos équipes, le publier sur votre intranet ou dans votre wiki projet, etc… Faites tourner !

Si ce rapport vous intéresse et que vous voulez entrer en contact avec un représentant de l’OWASP : contactez Sébastien Gioria de ma part (twitter @SPoint). Sébastien est un consultant indépendant en sécurité informatique, et il est également le représentant en France de l’OWASP.

[Edit] Sébastien Gioria nous signale en commentaire que le rapport de l'OWASP Edition 2007 est disponible en Français ici. L'édition 2010 en Français devrait aussi arriver sous peu... A suivre.

Durant notre récente journée de Conférence Web, organisée le 17 Novembre dernier chez Microsoft France, la dernière session de l’après-midi était animée par François Sutter, le Directeur Technique de l’agence Blue acacia et portait justement sur les questions de sécurité des applications Web. François a publié sa présentation (légèrement expurgée ;)) sur Slideshare. Vous pouvez donc la consulter, surtout si la lecture de l’Anglais n’est pas votre fort, car elle est en Français contrairement aux documents précédents.

La Sécurité Sur Le Web

View more presentations from Blue Acacia.

La session de François Sutter a rencontré un vif succès parmi les participants : pour plusieurs d’entre eux, ça a été comme un choc, une révélation. En effet, on constate dans “la profession” un nombre croissant d’acteurs qui viennent de divers horizons et arrivent au développement Web parce que c’est facile en apparence.

De même que passer son permis de conduire ne fait pas de vous un mécanicien, le fait de déployer un moteur de CMS ou un blog sur un serveur ne fait pas de vous un développeur ou un informaticien “pro”. Et du fait, beaucoup utilisent des outils dont ils ne maitrisent pas tous les aspects et ignorent tout simplement parfois dans quelle mesure ils peuvent présenter des risques, non seulement pour eux, mais surtout pour leurs clients !

Les cas et les anecdotes présentés en session par François étaient édifiants : sites de eCommerce sur lesquels on peut faire ses prix soi même, moteur de CMS hackables avec un simple navigateur et dans lesquels on peut entrer en admin en deux temps et trois mouvements, sites sur lesquels on peut récupérer des dumps et des backups avec tous les fichiers clients et les mots de passe, jusqu’aux numéros de CB stockés en clair (un procédé très étroitement encadré par la loi, rappelons-le). Bref, la liste est longue.

Et personne ne semble être à l’abri. La semaine dernière, c’est l’éditeur Symantec – pourtant un spécialiste des solutions de sécurité – qui a connu une telle mésaventure : faille sur leur site Web, récupération des fichiers clients et de listes de serials de produits. C’est la fête ! La faille ? Une banale Injection SQL, top 2 et top 3 dans les tableaux ci-dessus. Tellement banal !

Faites le test du “or 1=1” chez vous, sur le login/password de votre site Web, et vous verrez…

Essentiellement, le problème vient entre la chaise et le clavier : l’homme, qu’il soit développeur, “webmaster” ou ingénieur système. Mais loin de moi l’idée de leur jeter la pierre. L’objet de ce (long) billet est d’attirer l’attention de chacun sur le besoin d’éducation sur le sujet, passant par la formation des développeurs et des IT Pros, et par la mise en place dans chaque équipe de développement de processus de revue de code, ou encore de mise en place de “bonnes pratiques” au sein du code, clairement documentées et expliquées.

Et vous, chez vous, quelles pratiques avez-vous mises en oeuvre pour traiter ces problèmes ? J’attends vos commentaires avec impatience ;)

[Edit du 15/01/2010] : En complément à ce billet, et pour entrer plus concrêtement dans les détails techniques des différentes techniques courants et des moyens de s'en prémunir, je vous conseille la lecture de la traduction en Français réalisée par Frédéric de Villamil d'un très bon article publié sur le non moins excellent site Smashing Magazine. Enjoy :)