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. 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 :)

Comments

• Anonymous
  November 28, 2009
  Article très intéressant. Comme tu le dis, le constat est fait depuis longtemps et la situation ne s'améliore pas. Comme tu le mets aussi en évidence dans ton article les actions d'améliorations sont mises en œuvre au niveau société et tant que cela restera un paramètre de différentiation majeur entre les acteurs il n'y aura pas de progression globale.   Peut-être que ce sujet mérite un livre ;-)

• Anonymous
  November 28, 2009
  Personnellement, je fais toujours le test du "or 1=1" ;) Sinon, je développe principalement sous des frameworks PHP tel que Symfony ou Zend Framework qui se mettent pas mal en avant pour prévenir ce genre d'attaques par injection. Maintenant, il y a toujours des riques et c'est au développeur d'y penser. Très bon article et slides intéressants de Blue acacia !

• Anonymous
  November 28, 2009
  Un simple backup étant encore complètement étranger pour bon nombre de personnes (et d'entreprises), je n'ose imaginer une éventuelle prise de conscience en ce qui concerne la sécurité. Et la récente affaire de Zataz n'aide pas les choses.

• Anonymous
  November 28, 2009
  The comment has been removed

• Anonymous
  November 28, 2009
  Chez Oxatis, nous analysons dynamiquement les erreurs 400/500 et l’injection SQL est clairement la menace la plus importante.  Je suspecte même l’existence de robots pour cela. Pas une heure sans que nous ne puissions voir des urls ou de formulaires trafiqués et souvent avec beaucoup plus de subtilité que le Or 1=1… Relativisons, nous avons des milliers de sites, générons plusieurs millions de pagespar jours… Quand on analyse certains codes injectés, il y a de quoi avoir froid dans le dos, chez Oxatis, nous avons depuis très longtemps pris les devant et tout le monde est extrêmement sensibilisé. Maintenant, beaucoup de systèmes ont du se faire altérer voir « rinçér » avec des injections mais ces sites en font rarement la publicité ;-)

• Anonymous
  November 28, 2009
  Hello my dear, Très bon article ! Ah si seulement effectivement tous les devs pouvaient être former au dév sécurisé :) Bon slides aussi de la part de BlueAccacia, en tout ca très pragmatiques et qui dénote la prise en compte de ces problèmes. Même si certaines attaques sont plus poussées que ce qui est présenté, je suis impressionné de voir une agence Web qui va jusque la .... Pour ce qui est des docs, je tiens a signaler que le Top10 existe en francais depuis début 2008 =>  http://www.owasp.org/images/c/ce/OWASP_Top_10_2007_-_French.pdf La version 2010 va suivre bientot ! Peut etre a TechDays auront nous la chance de pouvoir présenter différentes choses ;)

• Anonymous
  November 28, 2009
  Et aussi, un autre document très instructif pour les Managers, chefs de projets etc... http://www.clusif.asso.fr/fr/production/ouvrages/resume.asp?id=211 Nous allons (le groupe de travail du CLUSIF) produire un document plus technique dans l'année prochaine...

• Anonymous
  November 29, 2009
  Bonjour article très intéressant. Comme vous dites, "le problème est entre la chaise et le clavier" mais il y a aussi un manque d'efficacité et de professionnalisme des antivirus comme le montrent les résultats du concours iawacs : http://securiteoff.blogspot.com/2009/11/concours-antivirus-edition-2010.html

• Anonymous
  November 29, 2009
  The comment has been removed

• Anonymous
  November 29, 2009
  oups, c'est la faute au lundi ;-) Pour la peine, je vais me mettre sur MacOS ;-) Bravo en tous les cas pour votre blog que je vais suivre dorénavant et... lire plus attentivement !

• Anonymous
  November 29, 2009
  @Clauer: je réagis au poste de Richard, mais on peut quand même ajouter sa remarque sur les serveurs... En effet il devient tellement simple de mettre des codes malveillants sur une appli coté serveur....Néanmoins il est vrai que les A/V ne sont pas actuellements prêts pour corriger cela http://video.google.com/videoplay?docid=1042293104444687505&hl=en et http://www.owasp.org/images/f/fa/Malicious_Developers_and_Enterprise_Java_Rootkits_-_Jeff_Williams.pptx

• Anonymous
  November 30, 2009
  Merci pour l'article et des liens utiles à l'intérieur, une cure de rappel reste toujours d'actualités. Pour réduire le risques, nous utilisons déjà des framework (NHibernate, EF, ...; ASP.NET) qui sont censés écarter les bases de la sécu (injection SQL notamment). Cela passe ensuite par la sensibilisation et de la revue de code, avec le leit motiv : ne jamais faire confiance dans ce que l'utilisateur envoie comme données : toujours vérifier ce qui rentre dans une méthode (programmation par contrats ?). Je vais de ce pas relire les différents documents que tu as mis en ligne, car connaitre les failles c'est bien, mais savoir les contourner, c'est mieux.

• Anonymous
  December 01, 2009
  Olivier : utiliser un framework ou une librairie externe n'est pas forcément la solution. Si le composant externe est vérolé, c'est toute ton application qui est en danger, ce n'est finalement que reporter la responsabilité de ta sécurité sur un tiers. Deux exemples : – Le jour où on a trouvé une faille dans PAX (un patch sécu kernel Linux) qui remettait en cause toute la protection BOF qu'il apportait. – La faille de sécu de Rails 1.2, pour ne citer qu'eux. En fait, comme le fait remarquer Christophe, tout est une question d'éducation des développeurs. Sauf que : – Soit les profs n'ont pas eté sensibilisés aux vulnérabilités de sécurité. – Soit, en les enseignant, ils passent pour des pirates formant d'autres pirates. Dans tous les cas, on n'est pas sortis.