Développement web sécurisé - incontournables (OWASP Top Ten)

Vous souhaitez améliorer la sécurité de vos applications web, mais ne savez pas par où commencer ? Vous avez entendu parler de l’OWASP Top Ten et souhaitez en savoir plus ? Cet article est fait pour vous ! La sécurité est un domaine incontournable dans le monde du développement informatique, et particulièrement au niveau du développement web / cloud.

Cependant, la sécurité web est un vaste sujet qui évolue à une vitesse fulgurante. De nombreuses nouvelles failles de sécurité sont découvertes chaque jour, ce qui peut sembler difficile à suivre.

Néanmoins, certaines catégories de vulnérabilités existant depuis plus de 10 ans (et parfois même plus de 20 ans) restent très répandues aujourd'hui : les injections SQL, les failles XSS, CSRF… On pourrait les appeler les incontournables. Et c'est par là qu'il faut commencer !

Par où ne pas commencer

Vous venez de rejoindre un projet et souhaitez évaluer l'état de la sécurité ? Ou l'on vous demande de renforcer la sécurité du projet sur lequel vous travaillez ? Des premières questions se posent alors : comment faire, et par où commencer ? Il n'y a pas qu'une seule réponse valide à ces questions : comme souvent, cela dépend du contexte. Mais une chose est sûre, si vous avez le sentiment que peu de choses ont été mises en place jusqu'ici au niveau de la sécurité du projet, il y a certaines démarches par lesquelles il ne vaut mieux pas commencer.

Par exemple, faire appel directement à une entreprise de pentests. Un pentest, ou test de pénétration, consiste à attaquer un réseau/logiciel/application pour tenter d'y découvrir des failles et de réaliser des actions normalement non autorisées, et ce dans un certain cadre légal et un contexte donné. De nombreuses entreprises spécialisées proposent leurs services de pentests, ce qui permet de trouver des failles qu'il n'est pas toujours évident d'identifier soi-même.

Et c'est là où réside le problème : si les pentesteurs passent du temps à identifier des failles que vous auriez pu découvrir vous-même, c'est à la fois du temps perdu pour cette équipe et de l'argent perdu pour vous. En effet, un pentest dure un nombre de jours (généralement déterminé à l'avance) et le temps que les pentesteurs passent à confirmer les vulnérabilités "évidentes", c'est du temps qu'ils ne passent pas à chercher des vulnérabilités plus avancées. Et de votre côté, cela aurait pu vous coûter moins cher d'identifier ces failles "évidentes" vous-même, plutôt que de payer un spécialiste pour le faire. Tout le monde y perd, donc!

Une autre approche non recommandée consisterait à s'inscrire directement à un programme de bug bounty. Un tel programme définit un cadre dans lequel n'importe qui (ou parfois un groupe déterminé de personnes) peut, dans une certaine limite, tester la sécurité d'une application. Lorsqu'une personne découvre une faille, elle la communique à l'entreprise propriétaire du projet, et celle-ci peut alors corriger la faille et rémunérer la personne selon des critères prédéterminés, en fonction de la criticité de la faille. Le montant payé dépend donc du risque lié à la faille, plutôt que du temps passé à rechercher la faille (à l'inverse d'un pentest, comme vu plus haut). Ici, c'est surtout vous qui allez y perdre : les pentesteurs vont vous signaler des failles "évidentes", et vous allez devoir les rémunérer pour cela. Cela vous coûtera, à nouveau, plus cher que si vous les aviez identifiées et corrigées avant de rejoindre le programme de bug bounty.

Mais alors, par où commencer ? Vous l'aurez deviné au titre de l'article, l'OWASP Top Ten est une très bonne première étape, comme nous allons le voir juste après. Les pentests et programmes de bug bounty sont des outils intéressants, mais à utiliser au bon moment : une fois que le projet a atteint un certain niveau de maturité en matière de sécurité.

Qu’est-ce que l’OWASP ?

L'OWASP (Open Web Application Security Project), c'est une communauté mondiale à but non lucratif dédiée à la sécurité des applications web. Son objectif est d’améliorer la sécurité des logiciels, par de la sensibilisation et via différents projets.

Ces projets sont très variés: on y retrouve Dependency-Track - un outil de suivi des vulnérabilités dans les dépendances, Juice Shop - une application vulnérable que l'on peut utiliser pour de l'apprentissage ou de l'entraînement, Zed Attack Proxy (ZAP) - un outil d'analyse dynamique de la sécurité d'une application, et plein d'autres.

Et bien entendu, parmi ces projets, il y a l'OWASP Top Ten: il s'agit d'un consensus sur les risques de sécurité les plus critiques des applications web. Concrètement, l'OWASP Top Ten est divisé en dix catégories de risques, triées par fréquence d'apparition. Ces catégories proviennent d'analyse de données de vulnérabilités de nombreuses entreprises, mais également d'un sondage de la communauté.

Chaque catégorie est en fait un ensemble de CWE - Common Weakness Enumeration. Une CWE est un type de faiblesse logicielle, c'est-à-dire une caractéristique d'une application pouvant contribuer à introduire une vulnérabilité. Par exemple, le fait d'utiliser des identifiants hardcodés, de ne pas hacher les mots de passes, de ne pas valider les URLs provenant de l'extérieur, etc.

Pour chaque type de faiblesse (CWE), on peut retrouver des vulnérabilités concrètes sur des applications existantes: il s'agit de CVE - Common Vulnerabilities and Exposures. Une CVE est une vulnérabilité découverte dans une application. Par exemple, la CVE-2021-44228 (Log4shell) est une vulnérabilité bien connue découverte sur la librairie Log4j en décembre 2021, et liée notamment à la CWE-502 (désérialisation de données non fiables).

En résumé, chacune des 10 catégories de l'OWASP Top Ten est composée d'un ensemble de types de faiblesses (CWE), chaque type de faiblesse étant lié à différentes vulnérabilités (CVE) découvertes sur des applications réelles.

L’OWASP Top Ten: les incontournables

Parcourons maintenant ces différentes catégories, et certaines des CWE qui les composent. Pour chacune des CWE, vous retrouverez plus d'informations (en anglais) sur le lien qui y est lié.

A01:2021-Broken Access Control

Il s'agit de tout ce qui concerne le contrôle d'accès: pages ou APIs non protégées (ou pas assez), élévation de privilèges, contournement des contrôles d'accès…

Path traversal: vulnérabilité exploitable lorsqu'un input utilisateur est utilisé dans un chemin, par exemple pour récupérer un fichier, et qu'il manque de la validation. Par exemple, pour une page /photo?path=albumId/photo44.jpg, si les photos sont stockées dans /data/ et que l'utilisateur donne la valeur "../etc/passwd" (un fichier sensible sur un serveur Linux) pour le paramètre path, sans validation supplémentaire, l'utilisateur risque de pouvoir récupérer le contenu de ce fichier sensible.
Cross-Site Request Forgery (CSRF): attaque consistant à réaliser une action non souhaitée au nom d'un utilisateur, via son navigateur. Cela peut se produire si l'utilisateur clique sur un lien envoyé par l'attaquant. Pour s'en protéger, une mesure de protection anti-CSRF doit être mise en place, mais attention que cette mesure ne protège pas les requêtes GET: il faut donc s'assurer que les requêtes réalisant des actions (création, modification, suppression…) n'utilisent pas GET.
Open redirect: cette attaque permet de rediriger un utilisateur vers un site malveillant, en lui faisant accéder à un lien valide d'une application légitime. Cela se produit généralement lorsqu'un site propose une page telle que /login?redirectAfterLogin=https://example.com, et que le paramètre de l'URL n'est pas validé. C'est risqué, car si le site malveillant est une copie conforme du site original, l'utilisateur risque de ne pas se rendre compte qu'il n'est plus sur le site original, et pourrait être amené à entrer ses identifiants.

A02:2021-Cryptographic Failures

Cela inclut les problèmes liés à la cryptographie, et au manque de cryptographie: chiffrement non forcé, utilisation d'algorithmes dépréciés, validation incorrecte de certificats…

Hash des mots de passes: il est plus que recommandé de ne pas stocker les mots de passes des utilisateurs en clair dans la base de donnée, mais bien de les hacher. Cependant, même lorsque le mot de passe est haché, des risques persistent, et une protection suffisante doit être mise en place (notamment, s'assurer que l'on utilise un algorithme de hachage suffisamment bon et avec les bons paramètres).
Transmission d'informations sensibles en clair: aujourd'hui, il apparaît comme une évidence qu'il faut utiliser des protocoles chiffrés (HTTPS, SFTP…) plutôt que leurs équivalents non chiffrés, étant donné que le trafic sur internet peut être écouté par de nombreuses personnes, potentiellement malveillantes. Cependant, un site utilisant HTTPS n'est pas forcément à l'abri de tout, et d'autres mesures doivent être mises en place (protection des cookies, HSTS…).

A03:2021-Injection

Tout ce qui est lié à l'utilisation de données non validées/sanitisées dans des requêtes: SQL, NoSQL, commande OS, LDAP…

Injection SQL: faut-il encore la présenter ? Cette injection bien connue est permise lorsque des valeurs provenant d'utilisateurs sont insérées dans une requête SQL, sans correctement valider ces valeurs. Cela peut permettre, selon le cas, de récupérer des informations sensibles depuis la base de données, ou d'ajouter, modifier ou supprimer du contenu.
Cross-Site Scripting (XSS): cette faille se produit lorsqu'un attaquant arrive à injecter du JavaScript sur une page d'un site légitime, visitée par d'autres utilisateurs.

A04:2021-Insecure Design

Il s'agit ici de tous les problèmes liés à l'architecture et à la conception de l'application, et non pas à son implémentation. Une implémentation peut être aussi parfaite que possible, elle ne pourra pas toujours résoudre tous les problèmes, notamment ceux liés à la conception de l'application.

Mauvaise compartimentalisation: la conception d'une application doit prendre en compte le fait que des fonctionnalités ou ressources nécessitant des accès ou permissions différentes, doivent être suffisament isolées. Par exemple, il est généralement recommandé de séparer les fonctionnalités d'administration des autres fonctionnalités.
Se baser sur la sécurité par l'obscurité: La sécurité par l'obscurité, c'est le fait de ne pas divulger certaines informations ou détails liés au fonctionnement des outils, librairies utilisées, dans le but d'assurer la sécurité du système. Ces informations peuvent être par exemple le fonctionnement d'un algorithme de chiffrement, ou la version du serveur web ou d'application (Tomcat, Apache httpd...). Le fait de ne pas divulguer cela n'est pas forcément un mal en soit, c'est plutôt le fait que divulguer l'information ait pour impact de diminuer la sécurité du système (cela ne doit pas être le cas).

A05:2021-Security Misconfiguration

On parle ici des problèmes de configuration de sécurité de logiciels, librairies et outils utilisés.

Headers de sécurité: pour les requêtes web, de nombreux headers de sécurité existent, et doivent être configurés correctement pour empêcher ou limiter certains types d'attaques: X-XSS-Protection, Content-Security-Policy (CSP), Access-Control-Allow-Origin (CORS)…
Page d'erreur: configurer des pages d'erreur spécifique (pour les erreurs 4xx, 5xx, etc.), c'est éviter que des informations sensibles soient divulguées à des attaquants, en cas d'erreur.

A06:2021-Vulnerable and Outdated Components

Les vulnérabilités, dans les dépendances. Il peut s'agir de vulnérabilités dans les librairies utilisées (incluant donc les dépendances transitives), sur l'OS, la base de donnée, le serveur d'applications, des APIs d'autres applications… S'en protéger signifie notamment faire un suivi des dépendances que l'on utilise, et des vulnérabilités découvertes dans ces dépendances. Cela peut se faire par exemple via l'outil OWASP Dependency-Track. Mais il faut aussi évidemment éviter l'utilisation de dépendances dépréciées, ou peu/plus maintenues (plus d'informations).

A07:2021-Identification and Authentication Failures

Il s'agit de failles liées à la confirmation de l'identité des utilisateurs (l'authentification), ainsi qu'à la gestion des sessions (mécanisme permettant de savoir quel est l'utilisateur actuellement connecté).

Contournement de l'authentification: avoir un mécanisme d'authentification en place, c'est bien, mais s'assurer qu'il ne soit pas possible de passer outre ce mécanisme, c'est mieux! Il est pour cela conseillé d'utiliser des mécanismes d'authentification et de session reconnus et sécurisés.
Authentification multi facteurs: le fait de ne pas utiliser plusieurs facteurs pour authentifier l'utilisateur est aujourd'hui un risque pour la sécurité de vos applications, qu'il s'agisse des comptes de vos utilisateurs, ou des comptes administrateurs. C'est un risque notamment en cas de phishing, ou de compromission du mot de passe d'utilisateurs (par exemple dans le cas où un utilisateur utilise le même mot de passe sur plusieurs sites, et que l'un d'entre eux s'est fait attaquer).

A08:2021-Software and Data Integrity Failures

Ces vulnérabilités se produisent lorsque l'intégrité des données reçues n'est pas vérifiée. Par exemple, lorsqu'un logiciel peut être mis-à-jour, il faut s'assurer que la mise-à-jour reçue n'est pas une fausse. Ou encore, que la librairie que l'on utilise est bien l'originale et non une copie falsifiée.

Désérialisation de données non fiables: sérialiser un objet (Java, C#...), c'est le transformer dans un format de donnée (json, xml, binaire...), pour pouvoir l'envoyer ou le stocker. Et désérialiser, c'est le processus inverse: retrouver les données à partir des données sérialisées. Cependant, les fonctionnalités de (dé)sérialisation sont souvent poussées, et deviennent dangereuses lorsque les données ne sont pas de confiance: attaque par déni de service (DoS), exécution de code à distance sur le serveur (RCE)…
Mass assignment: de nombreux frameworks (Spring, NodeJS...) permettent de mapper automatiquement des paramètres GET/POST à des objets du langage. Il est cependant parfois possible d'utiliser ce mécanisme pour modifier des valeurs qui n'étaient pas sensées pouvoir être modifiées. On peut par exemple imaginer l'exemple d'un formulaire d'inscription, recevant différents paramètres POST (username, email, password) qui sont mappés automatiquement à un objet User côté serveur. Si cet objet User possède une propriété booléenne isAdmin (à false par défaut), et que l'attaquant rajoute un paramètre POST isAdmin=true à la requête, l'utilisateur créé risque d'être administrateur.

A09:2021-Security Logging and Monitoring Failures

Cette catégorie comprend les problèmes liés au manque de logs et de surveillance de l'application et ses événements. Il est en effet important d'avoir assez de logs utiles, pour pouvoir par exemple identifier lorsqu'une attaque brute-force est en cours, ou lorsqu'un utilisateur tente de réaliser des actions interdites. Mais il faut aussi avoir des mécanismes en place permettant de détecter ces attaques ou actions, et d'alerter automatiquement.

A10:2021-Server-Side Request Forgery

Cette dernière catégorie ne contient qu'une seule CWE, du même nom. Une telle vulnérabilité est exploitable lorsqu'une application récupère une ressource distante via une URL fournie par l'utilisateur, et sans valider correctement cette URL (plus d'informations).

Formez-vous sur l’OWASP Top Ten

Chacune des catégorie de l'OWASP Top Ten mérite que l'on s'y intéresse, et cela nécessite donc de connaître les principales CWE de chacune d'entre elles. Nous en avons parcouru certaines, mais il y en a d'autres.

Pour se former, une bonne ressource est simplement le site officiel du projet OWASP Top Ten: https://owasp.org/www-project-top-ten/.

Vous y retrouverez des informations sur les catégories, et des liens pour s'informer sur chacune des CWE, qu'il est toujours utile de consulter: par exemple, même si vous connaissez la faille XSS, vous apprendrez peut-être d'autres techniques d'exploitation de cette faille, que vous n'aviez pas imaginé. D'autres ressources intéressantes:

https://cheatsheetseries.owasp.org/ : des antisèches sur de nombreux domaines de la sécurité web;
https://portswigger.net/web-security : des tutoriels sur diverses vulnérabilités web;
https://owasp.org/www-project-vulnerable-web-applications-directory/ : une liste d'applications vulnérables, que l'on peut utiliser pour s'entraîner à exploiter des vulnérabilités (une fois sur la page, ouvrez l'onglet "Online").
https://tryhackme.com/hacktivities : des tutoriels et ateliers (payants) sur la sécurité (web, mais pas que). Notamment cet atelier sur l'OWASP Top Ten: https://tryhackme.com/room/owasptop10.

SFEIR organise également différentes formations via le SFEIR Institute et les SFEIR Schools, et une formation sur le sujet pourrait être organisée sur demande. Une SFEIR School sur l'OWASP Top Ten existe, et les supports peuvent être trouvés à cette adresse: https://github.com/sfeir-open-source/sfeir-school-web-security.

Et ensuite ?

Vous former sur l'OWASP Top Ten vous permettra de découvrir et corriger de nombreuses vulnérabilités web sur vos applications, mais aussi d'éviter d'en introduire de nouvelles.

Votre prochaine étape pourrait être de mettre en place un secure SDLC (Software Development Life Cycle): intégrer la sécurité dans les différentes étapes du cycle de vie du logiciel. Le cycle de vie d'une application est divisé en différentes phases, typiquement: récupération des exigences, conception, développement, test, déploiement, maintenance. Que l'on travaille en agile ou en waterfall, ces phases sont bien présentes, et la sécurité doit être incluse dans chacune d'entre elles et non uniquement durant le développement ou les tests.

Pour mettre cela en place, différentes méthodologies existent: le NIST SSDF (open source), l'OWASP SAMM (open source), ou encore BSIMM (propriétaire). La première est une méthodologie dite prescriptive: elle décrit les pratiques à mettre en place, et les actions à réaliser pour y arriver. Les deux autres sont descriptives: elles décrivent les pratiques, mais pas comment y arriver concrètement. Ces dernières laissent donc plus de liberté d'implémentation, mais nécessitent également plus d'expérience du domaine.

Dans tous les cas, la mise en place d'une méthodologie de sécurité n'est pas une tâche aisée, et s'entourer de professionnels du domaine de la sécurité des applications (AppSec) est conseillé.

En conclusion…

Ne mettez pas la charrue avant les bœufs. De nombreux outils et techniques existent pour la sécurité, mais il faut les utiliser à bon escient, et surtout au bon moment.

L'OWASP Top Ten, c'est une très bonne première approche à la sécurité d'une application web. Ensuite, des méthodologies de développement (SDLC) peuvent être mise en place. Et une fois le projet plus mature en terme de sécurité, des actions telles que le pentest ou le bug bounty peuvent être envisagées, pour confronter la sécurité de votre application à la réalité du terrain.

Face à la très forte hausse des cyberattaques, il est indispensable de protéger ses applications. Maintenant, à vous de jouer: les défis de sécurité n'attendent que vous !