Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cyber:vulnerabilite:http_methods [2025/07/13 14:40] – admin
+++ cyber:vulnerabilite:http_methods [2025/07/13 14:44] (Version actuelle) – [Exemple 1] admin
@@ Ligne 73: / Ligne 73: @@
 ==== Exploiter ====
-Consulter les solutions de chaque challenge.
 ===== Conséquences potentielles =====
@@ Ligne 88: / Ligne 87: @@
   * Utiliser un pare-feu applicatif pour bloquer les requêtes HTTP non autorisées ou suspectes.
+====== Comment cela fonctionne ======
+Les scénarios suivants peuvent être joués via l’exploitation de cette vulnérabilité :
+  * L'utilisation de la méthode **DELETE** dans une requête HTTP pour supprimer une ressource sur le serveur ;
+  * L'utilisation de la méthode **PUT** dans une requête HTTP pour mettre à jour une ressource sur le serveur sans avoir l'autorisation adéquate.
+===== Exemple 1 =====
+Voici une configuration Apache potentiellement vulnérable aux modifications de méthodes HTTP :
+<code apache>
+<Directory /var/www/html>
+    AllowOverride None
+    Require all granted
+</Directory>
+</code>
+Cette configuration permet aux utilisateurs de l'application de faire des requêtes HTTP avec n'importe quelle méthode. Par conséquent, quelqu'un pourrait essayer d'envoyer une requête HTTP avec une méthode telle que DELETE ou PUT pour essayer de supprimer ou de modifier des données sur le serveur serveur.
+Voici une nouvelle version de la configuration Apache :
+<code apache>
+<Directory /var/www/html>
+    AllowOverride None
+    <Limit GET POST>
+        Require all granted
+    </Limit>
+</Directory>
+</code>
+Cette configuration permet uniquement les méthodes GET et POST, ce qui signifie que toutes les autres méthodes seront bloquées. Cette limitation peut aider à protéger un serveur contre les modifications non autorisées via les méthodes HTTP.
+===== Exemple 2 =====
+Un attaquant identifie une ressource protégée par le cookie de session sur le site "vulnerable.org". La ressource retourne les informations d'un utilisateur si celui-ci est authentifié via l'accès en GET à /api/v1/user/\{user_id\}/info
+L'attaquant a le user_id 1234, mais souhaite obtenir les infos de l'utilisateur ayant l'id 5678 :
+<code shell>
+$ curl -X GET vulnerable.org/api/v1//user/5678/info -i
+> < HTTP/2 401
+> [...]
+> Forbidden
+</code>
+En modifiant la méthode HTTP utilisée, l'attaquant accède aux données d'un autre utilisateur :
+<code shell>
+$ curl -X POST vulnerable.org/api/v1//user/5678/info -i
+> < HTTP/2 200
+> [...]
+> username: victim
+> [...]
+</code>
+====== CWEs ======
+  * [[https://cwe.mitre.org/data/definitions/650.html|CWE-650 : Trusting HTTP Permission Methods on the Server Side]]
+    * The server contains a protection mechanism that assumes that any URI that is accessed using HTTP GET will not cause a state change to the associated resource. This might allow attackers to bypass intended access restrictions and conduct resource modification and deletion attacks, since some applications allow GET to modify state.
+====== References ======
+URL :
+  * https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
+  * https://resources.infosecinstitute.com/topic/http-verb-tempering-bypassing-web-authentication-and-authorization/
+  * https://www.rfc-editor.org/rfc/rfc9110
 ====== Retour fiches vulnérabilités ======
   * [[cyber:vulnerabilite:accueil|Cyber fiches vulnérabilités]]