Dans notre métaphore du braquage de banque, c’est maintenant qu’on passe à l’action et qu’on exécute notre plan : c’est le jour J, enfilez vos masques !
Nous allons enfin passer à la phase la plus technique des tests d’intrusion web : la recherche de vulnérabilités dans l’application (nous pouvons déjà en avoir trouvé lors de la phase de cartographie ou de reconnaissance, mais l’essentiel va être fait à partir de maintenant).
Découvrez les vulnérabilités les plus courantes
Au fil de cette quatrième partie du cours, nous allons faire le tour des principales vulnérabilités que l'on peut trouver sur une application web, autrement dit les plus fréquemment identifiées.
Il existe aujourd’hui de nombreuses familles de vulnérabilités ; au sein de ces familles, des sous-groupes, et pour chaque sous-groupe, parfois des spécificités en fonction de la technologie utilisée par l’application.
Prenons par exemple les injections. Il s’agit d’une grande famille : elles sont réunies globalement dans la catégorie A03:2021-Injections :
Les injections côté client ;
Les injections côté serveur ;
les injections SQL :
les error-based
les boolean-based
les time-based
les injections de commande ;
les injections XXE.
On commence avec la première typologie de vulnérabilités : les injections XSS !
Manipulez l’utilisateur avec les XSS
Les injections XSS sont ce qu’on appelle des injections côté client : elles vont avoir un impact sur le client de l’application, donc l’utilisateur et non pas directement sur le serveur. Cette famille d’injection est la plupart du temps à combiner avec un peu d’ingénierie sociale pour que l’attaque fonctionne de bout en bout.
Il en existe principalement trois types d'injections XSS aujourd’hui :
Les XSS réfléchies (reflected, en anglais).
Les XSS stockées ou persistantes (stored, en anglais).
Les XSS DOM-based.
Nous n’allons parler que des XSS réfléchies car ce sont plus courantes et les plus simples à comprendre, mais également les moins dangereuses.
Si vous souhaitez vous renseigner sur les deux autres types de XSS, vous pouvez consulter l’OWASP.
Comment fonctionnent les XSS ?
Une XSS permet d’injecter du code HTML et JavaScript dans un champ ou un paramètre vulnérable. En injectant ce code, il est possible de faire exécuter du code JavaScript par le client (car c’est bien côté client qu’est exécuté le code JavaScript). Il est alors virtuellement possible de faire tout ce que permet le JavaScript dans le navigateur du client. En général, une XSS va servir à :
récupérer les cookies de session des utilisateurs s’ils ne sont pas bien protégés ;
rediriger l’utilisateur vers un site malveillant ;
modifier l’apparence ou le comportement de la page au bénéfice de l’attaquant, pour récupérer des informations de connexion, par exemple.
Prenons un exemple avec notre application example.com .
Nous avons un champ de recherche qui permet par exemple de rechercher un patient dans la base de données, et lors de la recherche, l’application nous indique
“Vous avez cherché [<nom du patient>]”.
Si l’application n’échappe pas les caractères spéciaux HTML, notamment <, > et / , alors vous avez probablement un vecteur pour une XSS !
Tous les exercices ont été faits sur Firefox dans une machine virtuelle Kali.
Souvenez-vous : je vous montre certaines vulnérabilités sur une application d'entraînement avant que nous les recherchions sur l’application example.com de notre commanditaire.
Faisons ensemble pas à pas la détection et l’exploitation de ce type de vulnérabilité :
Les vulnérabilités XSS simples présentées dans la vidéo de démonstration sont de plus en plus rares, il faut maintenant bien souvent faire preuve d’un peu d’ingéniosité.
Les balises <script> sont parfois bannies, et il faut faire appel à d’autres balises comme la balise <svg> qui permet de déclencher du JavaScript sur certains événements !
Comment se protéger de cette vulnérabilité ?
Il “suffit” d’échapper les différents caractères spéciaux HTML qui peuvent être envoyés par les clients en utilisant les fonctionnalités prévues à cet effet par les différents langages, comme la fonction htmlspecialchars en PHP. Je vous renvoie également vers le chapitre "Protégez votre code contre l'injection" du cours "Sécurisez vos applications web avec l'OWASP" qui traite du sujet.
En plus d’encoder correctement les caractères, vous pouvez préconiser la mise en place d’un WAF (Web Application Firewall) qui protège généralement efficacement contre ces vulnérabilités.
En résumé
Il existe trois types de vulnérabilités XSS :
XSS réfléchies (reflected) ;
XSS stockées (stored) ;
XSS DOM-based.
Ces vulnérabilités s'exécutent dans le navigateur de l’utilisateur victime, et sont généralement à associer avec un peu d’ingénierie sociale pour que l’attaque fonctionne.
Ces vulnérabilités servent à manipuler le comportement du navigateur du client, et sont utilisées pour piéger l’utilisateur en modifiant l’apparence ou le comportement de la page, en redirigeant l’utilisateur, ou encore en volant les cookies de session, quand c’est possible.
Dans le prochain chapitre, nous allons nous intéresser à notre première injection côté serveur, et plus précisément en base de données : les injections SQL, abrégées SQLi pour “SQL injection”.
