
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, …
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.
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.
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 ;-)