La méthode POST du protocole HTTP est une méthode qui peut être utilisée pour envoyer des données d'une requête client à un serveur web. Elle est souvent utilisée pour envoyer des données d'un formulaire HTML à un serveur web, mais elle peut également être utilisée pour envoyer d'autres types de données.
Pour exploiter cette méthode HTTP, il est nécessaire d'avoir accès à une application qui fonctionne sur un serveur acceptant les requêtes POST.
Naviguer sur l’application pour récupérer les endpoints et/ou pages de l’application qui acceptent les requêtes POST. En général, nous commençons par rechercher l'ensemble des formulaires étant donné que ces derniers utilisent très souvent la méthode POST lors de l'envoi des données à destination du serveur web.
L'objectif ici est de réaliser plusieurs soumissions de formulaires avec des données différentes. Il s'agira notamment de manipuler les valeurs des différents champs du formulaire afin de créer un comportement potentiellement anormal sur le serveur. Ce comportement anormal se caractérisera souvent par une réponse HTTP différentes des autres.
Consulter les solutions de chaque challenge.
Une exploitation réussie de ce type de vulnérabilité peut permettre :
Les contre-mesures suivantes peuvent être mises en œuvre :
Le scénario suivant peut être joué via l’exploitation de cette vulnérabilité :
Voici un exemple de configuration Apache qui pourrait être vulnérable à une attaque par la méthode POST :
<Directory /var/www/html> AllowOverride None Require all granted <Limit POST> Require all granted </Limit> </Directory>
Cette configuration permet à n'importe quel utilisateur d'envoyer une requête POST au serveur Apache, sans aucune restriction. Si un attaquant parvient à envoyer du code malveillant dans une requête POST, il peut alors compromettre le serveur.
On peut corriger cette configuration en limitant la taille des données envoyées par la requête POST, en exigeant que l'utilisateur qui soumet la requête soit préalablement authentifié. On veillera également à valider les entrées utilisateur.
Voici un exemple d'illustration d'un potentiel bypass d'accès à une ressource protégée via la modification du verbe HTTP GET en POST :
$ curl -X GET vulnerable.org/admin > [...] > < HTTP/2 403 > [...] $ curl -X POST vulnerable.org/admin > [...] > < HTTP/2 200 > [...]
Supposons que nous ayons un formulaire d'inscription avec les champs “Nom”, “Prénom” et “Adresse email”. Lorsque l'utilisateur soumet le formulaire, les données sont envoyées à un endpoint sur un serveur Web pour traitement.
Voici un exemple de requête POST envoyée à cet endpoint pour soumettre les données du formulaire :
POST /inscription HTTP/1.1 Host: www.example.com Content-Type: application/x-www-form-urlencoded Content-Length: 45 nom=John&prenom=Doe&email=john.doe@example.com
Explication de la requête :
Une fois la requête POST envoyée à l'endpoint, le serveur Web peut traiter les données envoyées et les stocker dans une base de données ou effectuer d'autres opérations nécessaires.
URL :