Les principales vulnérabilités web

1. Présentation

IDOR, Insecure Direct Object Reference, ou référence d’objet directe non sécurisée, est une vulnérabilité très répandue sur les applications web. Il s’agit d’un sous-ensemble faisant partie de la catégorie de mauvaise gestion du contrôle d’accès. Elle se produit lorsque l’accès à un objet est réalisé directement à l’aide d’un identifiant, mais que le contrôle d’accès est défaillant, permettant ainsi à l’utilisateur d’y accéder de façon non autorisée. Cet identifiant peut être un numéro de compte, un nom de fichier ou de dossier, un identifiant technique, etc. Il peut se trouver à divers endroits, que cela soit dans l’URL, dans un champ de formulaire, dans un en-tête HTTP, ou encore dans un cookie par exemple.

Grâce à cela, un attaquant peut accéder à une ressource d’un autre utilisateur. Pour cela, il lui suffit de connaître, ou de deviner, l’identifiant de la ressource de sa victime, qui est, dans le cas le plus simple, incrémental. De cette façon, si l’attaquant possède également une ressource, ayant par exemple pour identifiant la valeur 1500, il peut facilement tester la possibilité d’accéder aux ressources en itérant sur l’identifiant à partir de cette valeur.

L’exploitation d’une vulnérabilité IDOR mène généralement à une perte de la confidentialité, mais peut également impacter l’intégrité de la ressource ciblée ainsi que la disponibilité du service la mettant à disposition. Tout accès à une ressource par un utilisateur autre que son propriétaire n’est pas forcément un incident de sécurité. C’est pour cette raison qu’il est important de bien connaître le contexte d’utilisation avant de remonter de tels problèmes.

1. Présentation

1. Présentation

L’injection de commande, ou OS (Operating System) injection, est une faiblesse permettant à un attaquant d’exécuter des commandes arbitraires sur le système d’exploitation hébergeant l’application vulnérable. Cette vulnérabilité survient lorsque l’application utilise des données non fiables et non assainies, à un interpréteur de commandes système (shell system). Les commandes ainsi envoyées par l’attaquant sont exécutées avec les droits et permissions de l’application vulnérable :

L’impact dépend du contexte, mais il est généralement significatif pour le système vulnérable. L’attaquant est en mesure d’accéder, d’altérer les informations et les services dont l’application a accès, menant ainsi à des accès non autorisés, des fuites de données ou encore à du déni de service.

Si cela ne suffit pas, l’attaquant peut tenter d’identifier d’autres faiblesses ou vulnérabilités sur le système d’exploitation lui-même, afin de récupérer des privilèges plus importants. L’obtention des privilèges de type root ou administrateur étant considéré comme un objectif de grande valeur ; cette technique, très répandue, est appelée Local Privilege Escalation (LPE). Une autre possibilité pour un attaquant est d’utiliser le serveur compromis comme pivot afin d’accéder à des ressources et à des machines internes à l’entreprise, et dans le pire des cas compromettre l’entièreté du système d’information.

La donnée non fiable peut être utilisée en tant que nom de commande, d’un argument ou même d’une option. À titre d’exemple, la commande ci-dessous permet d’afficher une liste détaillée...

1. Présentation

L’injection de code est une vulnérabilité permettant à un attaquant de faire exécuter du code arbitraire à l’application vulnérable. Dans le cadre d’une telle injection, les possibilités d’exploitation sont limitées par les possibilités du langage de développement utilisé par l’application vulnérable. L’exploitation d’une telle vulnérabilité peut mener à une perte de confidentialité, une perte d’intégrité et une perte de disponibilité du service.

$code = "echo 'J\'affiche du texte';"; 
eval($code); 

J'affiche du texte 

$code = $_GET['code']; 
eval($code); 

eval("system('whoami');"); 

$fichier = "ficher_a_inclure.php"; 
include $fichier; 

$file = $_GET['page']; 
include $file; 

1. Présentation

Le Cross-Site Scripting (XSS) est une vulnérabilité de type injection qui survient lorsqu’une page web intègre des données non fiables non assainies lors de sa génération. La principale différence entre cette injection et les autres types d’injection réside dans le fait que l’exécution du code malveillant par l’interpréteur se produit au niveau du navigateur web, côté client, et non de l’application ou du serveur.

Le code injecté, généralement du JavaScript, s’exécute lorsque la victime visite la page web ainsi altérée. En fonction de l’application, de la nature de la vulnérabilité et des protections en place, l’exécution de code JavaScript arbitraire peut permettre des attaques de défaçage, la compromission des comptes utilisateurs, l’exécution d’actions sensibles sur l’application à l’insu de sa victime, ou encore l’exfiltration de données sensibles.

Le code non malveillant généralement utilisé pour prouver l’existence d’une telle vulnérabilité est l’apparition d’une boîte de dialogue lors de son exécution dans le navigateur.

<script>alert('XSS');</script> 

Le code JavaScript ainsi injecté ne s’exécute que sur la page vulnérable, mais peut avoir un impact bien au-delà.

1. Présentation et protection

La mauvaise gestion de l’authentification et de session ne constitue pas une vulnérabilité en soi, mais plutôt un ensemble de faiblesses affectant ces thématiques. Cette catégorie regroupe des problématiques autour des énumérations, des attaques par force brute, du stockage des mots de passe, des fonctionnalités de mots de passe oubliés ou encore des fixations de session. Les conséquences varient en fonction de la faiblesse constatée, mais la confidentialité est généralement le premier critère impacté et peut mener à la compromission des comptes utilisateurs.

Ces thématiques sont variées et dépendent du contexte de l’application, pour ces raisons, cette section ne saura être exhaustive.

1. Présentation

L’autorisation et le contrôle d’accès sont deux mécanismes essentiels pour garantir la sécurité des applications web. Ils permettent de s’assurer que l’accès aux ressources de l’application soit restreint aux seuls utilisateurs autorisés. La mauvaise gestion du contrôle d’accès regroupe un ensemble de vulnérabilités, dont celle des références directes non sécurisées (Insecure Direct Object Reference, IDOR) déjà étudiées, des vulnérabilités CSRF, du contournement des contrôles d’accès en manipulant l’URL, des attaques par traversée de chemin, de la manipulation des cookies ou autres identifiants, etc.

Il ne faut pas confondre l’authentification et le contrôle d’accès, bien qu’interdépendants. L’authentification est le processus permettant de vérifier l’identité d’un utilisateur, son objectif principal est de s’assurer que l’utilisateur est bien celui qu’il prétend être, tandis que le contrôle d’accès est le processus qui détermine les droits d’accès et les permissions des utilisateurs après qu’elle ait été authentifiée. L’objectif du contrôle d’accès est de garantir que les utilisateurs n’ont accès qu’aux ressources auxquelles ils sont autorisés.

Les risques les plus notables d’un manque de contrôle d’accès est l’exposition d’informations sensibles à un acteur non autorisé, la modification ou la destruction de données, ainsi que l’accès inattendu à des fonctionnalités par des utilisateurs ne disposant pas les privilèges requis.

Élévation horizontale des privilèges

L’absence, ou un contournement possible du contrôle d’accès peut ouvrir la porte à des attaques d’élévation de privilèges, qui peuvent être horizontale et/ou verticale. L’élévation horizontale des privilèges se produit lorsqu’un attaquant, disposant initialement d’un...

1. Présentation

Une vulnérabilité d’Open Redirect survient lorsqu’une application permet à un utilisateur d’être redirigé vers une URL arbitraire de manière non contrôlée, l’URL de destination étant récupérée depuis une donnée non fiable.

Un attaquant peut abuser de ce manque de contrôle afin de mener des attaques par phishing, en redirigeant les éventuelles victimes vers un site frauduleux. Une application vulnérable à ce type d’attaque peut présenter le scénario suivant : lorsqu’un utilisateur non authentifié cherche à accéder à une page nécessitant des privilèges, l’application l’invite à s’authentifier en le redirigeant vers le formulaire de connexion. Afin de conserver l’information sur la page souhaitée initialement par l’utilisateur, l’application transmet le nom de la page dans un paramètre d’URL.

https://application-vulnerable.com/?redirect=page_initiale 

Ainsi, après que l’utilisateur s’est authentifié, et s’il détient les autorisations nécessaires, il sera redirigé vers la page initialement souhaitée. Malheureusement, lorsque la redirection est mal sécurisée, elle peut permettre la redirection vers un site arbitraire de la façon suivante :

https://application-vulnerable.com/?redirect=https://attacker.com 

Sachant cela, un attaquant peut décider d’exploiter cette faiblesse en partageant un tel lien à sa victime. Le site malveillant proposera une page ressemblant au formulaire d’authentification de l’application vulnérable, mais affichera un message indiquant que le nom d’utilisateur ou le mot de passe est incorrect, invitant sa victime à renseigner ses informations de connexion une nouvelle fois. L’attaquant, maintenant en possession des informations de connexion de la victime, peut terminer son attaque de la façon qu’il souhaite.

Cette attaque peut sembler similaire à toute tentative de phishing où un attaquant incite...

1. Présentation

CSRF est une vulnérabilité permettant à un attaquant de faire exécuter une action à sa victime, et à son insu, en exploitant le lien de confiance entre l’application et le navigateur de la victime.

L’exemple le plus simple est une action se reposant sur le verbe HTTP GET. L’exemple suivant est une application permettant à un utilisateur de supprimer son compte en suivant le lien ci-dessous :

https://application-vulnerable.com/profile?delete=1 

Un attaquant peut exploiter cette fonctionnalité, en envoyant un lien pointant vers cette URL à la victime, entraînant ainsi la suppression de son compte. L’exploitation d’une telle vulnérabilité est tout aussi bien réalisable lorsque la fonctionnalité repose une requête POST. Pour cela, l’attaquant crée une page contenant du code visant à exécuter l’action sur l’application vulnérable, par exemple un formulaire HTML auto-envoyé grâce à du JavaScript.

<form id="deleteForm" action="http://application-vulnerable.com/
profile" method="POST"> 
  <input type="hidden" name="id" value="5"> 
  <input type="submit" name="delete" value="Supprimer"> 
</form> 
 
<script> 
  document.getElementById('deleteForm').submit(); 
</script> 

Le principe est que lorsque la victime consulte cette page, le formulaire est automatiquement envoyé. Étant donné que la requête s’effectue dans le contexte de la victime, son cookie d’authentification est également envoyé, supprimant ainsi son compte sur la plateforme.

POST /profile HTTP/1.1 
Host: application-vulnerable.com 
Content-Length: 21 
Content-Type: application/x-www-form-urlencoded 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/
537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 
Cookie: PHPSESSID=g2b5op6lc2grld9n1d295u81o2 
Connection: close 
 
id=5&delete=Supprimer 

Soit le schéma suivant :

Mais pourquoi une telle exploitation est possible et quelles en sont les limites ?