OWASP Top 10 : Nouveau millésime

Le mois de novembre 2017 aura été fort en émotions : Tandis que le bitcoin passait la barre des 8,000$ et que le beaujolais nouveau coulait à flot, l’OWASP sortait la dernière mouture de son désormais célèbre « TOP 10 » - disponible sur le site de l'OWASP.

Pour rappel, le TOP 10 de l’OWASP (Open Web Application Security Project) est un projet visant à maintenir à jour la liste des 10 risques de sécurité les plus critiques affectant les applications Web. Ce classement est souvent utilisé dans les formations à la sécurité Web et dans la plupart des solutions de sécurité qui de près ou de loin protègent ou évaluent la sécurité des applications Web (firewall applicatifs, scanners de vulnérabilités, analyseurs de code, …). 

Ce classement 2017, contrairement aux années précédentes, n’est plus uniquement basé sur la « vision » de l’OWASP sur le sujet. Le processus méthodologique a été entièrement revu. Il repose ainsi sur les remontées de 500 utilisateurs et de 40 sociétés spécialisées dans le domaine de la sécurité des applications. La liste des contributeurs et les données techniques issues de leurs remontées sont disponibles en Open Source sur Github. En outre, les statistiques concernent un panel de plus de 100,000 applications et services Web.

Le Top 10 de l’OWASP a pour but d’informer sur l’existence de ces vulnérabilités et de fournir des guides simplifiés sur les bonnes pratiques pour s’en prémunir. Ces guides sont disponibles sur le site de l’OWASP et s’adressent aux développeurs, architectes, chef de projets, managers…

La dernière version datant de … 2013, il était temps de la mettre à jour. Et, si la première release candidate (sortie en avril 2017) ressemblait fortement à celle de 2013, force est de constater que la version définitive apporte de nombreuses améliorations – certaines plus surprenantes que d’autres. Le projet a manifestement gagné en maturité. Il prend désormais en compte les technologies « modernes » de développement qui ont explosé ces dernières années : Microservices, JavaScript, containers, gestion des secrets, exposition plus importante de code au sein d’API, « one-page applications » avec services RESTful, décentralisation de l’authentification, …

Décryptage

Ce qui ne change pas 

Sans surprise (mais un peu blasé quand même…), le risque numéro 1 reste l’attaque par Injection, notamment celle qui permet l’exécution de code à distance : Injection SQL, NoSQL, LDAP, … jusqu’aux injections de code au niveau système qui sont les plus dévastatrices. Dans les exemples d’actualité récents, on peut (encore) citer la vulnérabilité affectant Struts ou celle affectant CISCO UCS et qui permet l’exécution de code sous l’identité root à partir d’une simple requête WEB mal contrôlée par le serveur.

En deuxième position, les risques liés à une gestion incorrecte de l’authentification ou du suivi des sessions. On parle ici de compromission de mot de passe, de clé ou de jeton d’authentification ou de session. 

Dans le peloton du milieu, on trouve toujours les problèmes liés à la défaillance des systèmes de contrôles d’accès aux ressources. On notera que les références directes non sécurisées ont été fusionnées avec le manque de contrôle d’accès fonctionnel, ce qui est logique à priori. A priori seulement car, et cet avis n’engage que moi, les références directes restent un vrai problème – qui n’a rien à voir avec le contrôle d’accès : Imaginez un site Web de petites annonces. Elles sont toutes accessibles sans authentification car c’est le principe du site. Pourtant il n’est pas souhaitable que n’importe qui puisse énumérer l’intégralité des annonces afin d’aspirer le site par exemple… voilà ce que permet une référence directe, et aucun système d’authentification ne règle ce problème-là. C’est un vrai problème de conception pas si simple à régler – dommage donc que le TOP 10 n’en fasse plus explicitement mention.

Enfin, les problèmes de mise à jour des composants et les mauvaises configurations restent elles-aussi aux mêmes places que précédemment. L’usage des scanners de vulnérabilités n’est manifestement toujours pas industrialisé dans les organisations vulnérables.

Ce qui a été modifié

L’exposition de données sensibles passe de la 6ème à la 3ème place. Pas vraiment étonnant dans une actualité où les fuites de données sont quotidiennes. Aucune idée si l’OWASP est sensible à la GDPR, mais cela va dans le même sens : Une fuite d’information sensible coûte de plus en plus cher et met de plus en plus de business en péril.

Exit les attaques CSRF : Seules 5% des applications restent vulnérables. Il faut dire qu’aujourd’hui n’importe quel Framework de développement embarque ce type de protection par défaut. Et rappeler que ces protections sont efficaces… sous réserve que l’application ne souffre pas de Cross Site Scripting.

Exit également la catégorie « A10 – Redirection et transferts non validés ». Bien que présentes dans 8% des applications, ces vulnérabilités ne représentent par un risque aussi important que ceux ajoutés dans le Top 10 2017.

Ce qui a été ajouté

A4 : 2017 - XML External Entities (XXE)

• Surprenant… très surprenant même. Premièrement parce qu’on aurait tendance à classer ces vulnérabilités dans les attaques par injection (injection XML dans le cas présent). Deuxièmement parce que ce type d’attaque nécessite de coder avec des moufles ou d’utiliser des processeurs XML dépréciés ou vraiment mal configurés. Reste toutefois qu’en cas d’exploitation réussie, l’impact est très important – ce qui explique probablement cette 4ème place.

A8 : 2017 – Insecure deserialization

• Rien à dire ici. Rappelons que la sérialisation permet de faire passer des objets ou des structures de données plus ou moins complexes entre deux programmes en les transformant dans un format « sérialisé », compréhensible par les deux parties. Les problèmes surviennent au moment de reconstituer, c’est à dire « dé-sérialiser », l’objet d’origine : un attaquant envoyant des données malicieuses spécifiquement sérialisées pourra tenter d’exploiter des vulnérabilités sur le système en charge de la désérialisation. Ce type d’attaque est souvent basé sur des conversions de type et peut conduire à des élévations de privilèges, des attaques par injection…

A10 : 2017 – Insufficient Logging & Monitoring

• Bravo ! C’est effectivement incroyable de voir autant d’applications, y compris des applications bancaires exposées sur Internet (ça me démange de balancer des noms…), qui n’ont aucun logs (je ne dis pas « peu », je dis bien « aucun ») ! Dans le meilleur des cas on va loguer les stacktrace JAVA à des fins de debugging (sur la prod, oui, plus pratique…), mais jamais à des fins de sécurité : Connexion, déconnexion, accès aux modules / fonctions sensibles, … sont pourtant des évènements qu’il est indispensable de journaliser. Rappelons que la surveillance en général et celle des logs applicatifs en particulier est essentielle pour détecter tout dysfonctionnement de la sécurité. Qu’on utilise un produit de type SIEM ou, mieux, un service de type SOC pour surveiller ses applications est juste indispensable aujourd’hui. L’OWASP dans son rapport rappelle qu’en moyenne 200 jours s’écoulent entre une intrusion et sa détection – et que bien souvent la détection n’est pas faite par l’entreprise vulnérable, mais par l’un de ses partenaires ou clients. Rappelons enfin que le risque zéro n’existe pas et que tôt ou tard une vulnérabilité affectera vos systèmes. Ce qui compte ce n’est pas d’être invulnérable, mais de réduire au maximum le temps entre la détection de la vulnérabilité et sa suppression. Les logs sont souvent indispensables pour réduire cette période au maximum.

La surprise du chef 

On garde le meilleur pour la fin : Le Cross-Site Scripting dégringole de la 3ème place à la 7ème place ! Là c’est totalement incompréhensible : contournement de système d’authentification, injection de code côté client, contournement de protection CSRF, phishing, … sont autant de vecteurs d’attaques facilités par le Cross Site Scripting. L’OWASP réduit le XSS à la défiguration de site, les redirections et l’usurpation de session (classée en 2ème position par ailleurs). Avec l’explosion du Javascript, c’est vraiment très surprenant de le voir aussi bas dans le classement.

A croire qu’il y a eu une faute de frappe entre A4-XXE et A7-XSS ;-)