Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Sécurité des applications web
  3. Les principales vulnérabilités web
Extrait - Sécurité des applications web Stratégies offensives et défensives
Extraits du livre
Sécurité des applications web Stratégies offensives et défensives
1 avis
Revenir à la page d'achat du livre

Les principales vulnérabilités web

Introduction

Il est difficile, pour ne pas dire impossible, d’étudier de manière exhaustive l’ensemble des vulnérabilités existantes pouvant impacter les applications web. L’objectif n’est pas d’examiner des vulnérabilités spécifiques, telles que celles identifiées par des CVE et s’appliquant à des produits et des versions spécifiques, mais plutôt d’analyser les faiblesses techniques sous-jacentes auxquelles les applications web dans leur globalité peuvent être exposées. L’informatique étant en perpétuelle évolution, cette liste de faiblesses ainsi que les techniques d’exploitation, ne fait que croître au fur et à mesure que les connaissances s’améliorent et que de nouvelles technologies émergent.

La grande majorité des risques ou des vulnérabilités examinés figure actuellement, ou a figuré, dans les documents de sensibilisation TOP TEN de l’OWASP. Chaque étude commencera par une explication détaillée du fonctionnement de la vulnérabilité ainsi que de son potentiel impact. Une seconde partie proposera un ensemble de correction permettant d’y remédier. Pour terminer, et afin de consolider la compréhension de la faiblesse étudiée, des exercices pratiques, généralement...

Insecure Direct Object Reference

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.

Dans le cas de l’IDOR, le terme « objet » est utilisé de manière générique pour désigner une ressource.

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.

images/06EP01.png

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.

Dans un contexte d’API, cette vulnérabilité...

Injection SQL

1. Présentation

a. Principe de fonctionnement

L’injection SQL (SQLi) fait partie de la catégorie des injections présente dès la première version du Top Ten de l’OWASP, publiée en 2003, il y a donc maintenant plus de vingt ans. Il s’agit probablement du type d’injection le plus courant. Son impact peut être très important et porter atteinte à la confidentialité des données, mais également à leur intégrité et à la disponibilité du service. Cette vulnérabilité survient lorsque l’application effectue des transactions avec son système de gestion de base de données (SGBD) en incluant des données non fiables, provenant par exemple d’un utilisateur de l’application, sans s’assurer que ces données soient inoffensives pour le système. Ces données peuvent provenir d’un paramètre présent dans l’URL, d’un champ d’un formulaire, mais également d’un cookie, d’un en-tête HTTP, etc. En somme, tout ce qui permet à un utilisateur de renseigner de la donnée. L’insertion sans précaution de ces données non fiables au sein d’une requête SQL peut permettre à un utilisateur malveillant d’altérer l’objectif initial de la requête, et ainsi modifier le comportement attendu de l’application vulnérable.

Généralement, les applications modernes ont besoin de sauvegarder et de stocker un ensemble de données. Ces données sont essentielles pour le bon fonctionnement de l’application, il peut s’agir d’informations relatives aux comptes des utilisateurs, telles que les noms d’utilisateurs, les mots de passe, les adresses e-mail, ainsi que le contenu des messages pour un forum ou les détails des commandes et des paniers dans le cas d’une application de e-commerce. Pour bien comprendre les différentes interactions, il convient de faire quelques rappels sur l’utilisation d’une base de données SQL par une application.

Les explications fournies ci-dessous se concentrent spécifiquement sur le système de base de données MySQL, plus précisément sur MariaDB, qui est un clone de MySQL....

Injection de commande

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 :

images/06EP87.png

Les commandes injectées doivent être adaptées au système d’exploitation sur lequel s’exécute l’application présentant la vulnérabilité. Les exemples donnés dans cette section s’appliquent au système Unix/Linux.

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...

Injection de code

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.

a. La méthode eval()

En PHP, la méthode eval() permet l’exécution de code arbitraire passé en paramètre. Le code à évaluer doit contenir directement les instructions PHP (sans les balises ouvrantes et fermantes) :

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

Dont l’affichage sera le suivant :

J'affiche du texte 

Bien que très pratique de prime abord, cette méthode est très dangereuse lorsque le code à évaluer contient des données non fiables.

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

Dans un tel cas, un attaquant peut injecter du code malveillant, et ainsi modifier le comportement normal de l’application. Dans certains cas, l’attaquant peut être en mesure d’exécuter des commandes système en utilisant les fonctionnalités du langage :

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

b. Inclusion de fichiers

En PHP, les structures de langages include et require permettent l’inclusion de fichiers afin d’évaluer le code qu’ils contiennent.

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

Ce mécanisme permet ainsi aux développeurs de mutualiser du code au sein d’un seul fichier, et de l’inclure dans les pages le nécessitant. Dans l’exemple suivant, l’application inclut le fichier PHP dont le nom est spécifié en paramètre d’URL, pouvant représenter une des différentes pages ou fonctionnalités de l’application.

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

Malheureusement, si une personne mal intentionnée peut inclure un fichier...

Cross-Site Scripting

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 défaçage dans le cas d’une XSS fait référence à la modification non autorisée du contenu d’un site web par l’injection de code malveillant, souvent dans le but de perturber ou de compromettre l’intégrité du site.

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> 
images/06EP102.png

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

a. Les possibilités d’une XSS

Il est essentiel de comprendre et d’explorer les possibilités qu’offre XSS, en prenant en compte le contexte de l’application vulnérable. Que cela soit dans le cadre d’un test d’intrusion, d’un programme de recherche de bogues (bug bounty), ou lors de discussions avec les différents acteurs du projet (développeurs, chef d’équipe, etc.), l’affichage d’une boîte de dialogue en tant que preuve de concept peut ne pas suffire. Il n’est...

Mauvaise gestion de l’authentification et de session

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.

a. Sécurisation des communications

Les communications entre les utilisateurs et l’application doivent être protégées contre les différentes attaques liées à l’écoute, à l’interception ou à l’usurpation du serveur. Plusieurs mécanismes doivent être mis en place pour cela :

  • L’utilisation du protocole HTTPS est maintenant majoritaire et peu de sites ne le proposent pas. Sa mise en place va permettre de protéger la confidentialité et l’intégrité des échanges tout en s’assurant de l’authenticité du serveur. Le chapitre Fonctionnement de TLS explique en détail son fonctionnement.

  • L’utilisation de l’en-tête HTTP de sécurité HSTS (HTTP Strict Transport Security) est une mesure additionnelle vivement recommandé permettant de s’assurer que l’accès à l’application en utilisant le protocole HTTP se fasse automatiquement par le protocole HTTPS. Son fonctionnement est décrit dans le chapitre Les principaux en-têtes HTTP de sécurité.

  • L’utilisation de l’option Secure des cookies sensibles, dont principalement le cookie d’authentification, permet de s’assurer qu’ils ne sont transmis seulement si la communication est protégée par HTTPS, empêchant leur interception. Soit en PHP la configuration...

Mauvaise gestion du contrôle d’accès

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...

Open redirect

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...

Cross-Site Request Forgery

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 :

images/06EP128.png

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

a. Same-Origin Policy

Same-Origin...