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 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 (13)

  1. gsempe says:

    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 😉

  2. 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 !

  3. l'Ours says:

    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.

  4. CLaueR says:

    La bonne nouvelle c’est qu’avec l’explosion à venir sur le Web, les prestations de conseil autour de ces sujets ont clairement de l’avenir 😉

    @Vincent Oui heureusement les frameworks PHP et ASP.NET permettent maintenant de "repousser" les problèmes vers les couches supérieures. Mais on n’est pas à l’abri d’un CMS codé avec les pieds, ou dans un CMS codé proprement pas à l’abri d’un plug-in présentant des failles de sécu. Malheureusement c’est la course perpétuelle la recherche de la sécurité, on n’en verra pas la fin 😉

    @L’Ours En effet, les besoins d’éducation des utilisateurs sont énormes. Je ne parlerai pas de celles et ceux qui font de la déinformation en vendant des bases de données "Unbreakables" ou des systèmes d’exploitations très fancy "qui ne sont pas sujets aux Virus" et qui sont donc ‘achement plus cools 😉

  5. 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é 😉

  6. S. says:

    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 😉

  7. S. says:

    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…

  8. richard says:

    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

  9. CLaueR says:

    Bonjour Richard,

    On ne parle pas de la même chose : moi je traite de la sécurité applicative au niveau du code "server side" qui tourne sur le serveur Web. Les anti-virus ont surtout un rôle sur les postes "clients", ie sur les PC (et les Mac parfois 😉 des internautes.

    Merci pour votre commentaire, toutefois.

  10. richard says:

    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 !

  11. S. says:

    @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

  12. Olivier says:

    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.

  13. 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.

Skip to main content