Les cours du BTS SIO

Outils pour utilisateurs

Outils du site

Piste : • http_methods
cyber:vulnerabilite:http_methods

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
cyber:vulnerabilite:http_methods [2025/07/11 15:21] – IOUT admincyber:vulnerabilite:http_methods [2025/07/13 14:44] (Version actuelle) – [Exemple 1] admin
Ligne 1: Ligne 1:
-====== Analyse de logs ====== +====== HTTP - Methods ======
-LFSDHFSDLMGHSFDLMHG+
 ===== Description ===== ===== Description =====
  
-Dans le domaine de l'analyse forensique, l'analyse de logs consiste à exploiter les journaux d'événements et les données de trace (logs) pour reconstituer les activités qui ont eu lieu sur un système informatique.  
  
-Cette activité s'avère indispensable lorsqu'il s'agit d'enquêter sur un incident de sécurité (attaque, défaillance, comportement déviant, ...).+**Les méthodes HTTP sont des verbes utilisés dans les requêtes HTTP pour indiquer l'action à effectuer sur une ressource. Les méthodes HTTP les plus courantes sont GET, POST, PUT et DELETE. Chacune de ces méthodes est utilisée dans différentes situations et peut être utilisée selon les besoins de l'application.**
  
-===== Prérequis d'exploitation =====+D'après la [[https://www.rfc-editor.org/rfc/rfc9110|RFC 9110]] : 
 +  * **GET** sert à obtenir une représentation de la ressource spécifiée. Par exemple, on récupérera des informations sur un utilisateur avec un GET (GET /api/v1/users/1234). 
 +  * **POST** sert à soumettre une nouvelle entité à la ressource spécifiée. Par exemple, on enregistrera un nouvel utilisateur sur une plateforme avec un formulaire soumis via un POST (POST /api/v1/users). 
 +  * **PUT** sert à remplacer les données de la ressource spécifiée avec les données de la requête. Par exemple, on mettra à jour les informations d'un utilisateur avec la méthode PUT (PUT /api/v1/users/1234) 
 +  * **DELETE** sert à supprimer la ressource spécifiée. Par exemple, on supprimera un utilisateur avec la méthode DELETE (DELETE /api/v1/users/1234)
  
-Pour mener une analyse de logs, il est impératif d'avoir accès aux fichiers de journaux d'événements du système concerné.+Exemple d'une requête de type GET :
  
-==== Connaissances nécessaires ====+<code http> 
 +GET /example/page.html HTTP/1.1 <- Position de la méthode de type GET  
 +Host: www.example.com 
 +User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 
 +Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 
 +Accept-Encoding: gzip, deflate, br 
 +Accept-Language: en-US,en;q=0.9 
 +Cookie: sessionID=12345; username=john.doe 
 +</code>
  
-  * Compréhension du fonctionnement des systèmes informatiques ; +Réponse du serveur : 
-  * Connaissance des techniques d'attaques utilisées et des vulnérabilités pouvant être exploitées pour effectuer une analyse de log efficace ; + 
-  * Maîtrise des formats de logs courants et des protocoles réseau.+<code html> 
 +HTTP/1.1 200 OK 
 +Date: Thu, 31 Mar 2023 10:15:00 GMT 
 +Content-Type: text/html; charset=UTF-8 
 +Content-Length: 3456 
 +Connection: keep-alive 
 +Server: Apache/2.4.41 (Ubuntu) 
 +X-Powered-By: PHP/7.4.3 
 + 
 +<!DOCTYPE html> 
 +<html> 
 +<head> 
 +  <title>Example Page</title> 
 +</head> 
 +<body> 
 +  <h1>Welcome to the Example Page</h1> 
 +  <p>This is an example page.</p> 
 +</body> 
 +</html> 
 +</code> 
 + 
 +On notera que toutes les APIs et toutes les applications ne respectent pas nécessairement la RFC. 
 + 
 +Les services web exposent parfois involontairement des ressources qui ne devraient pas être accessibles, mais qui le sont via la modification de la méthode HTTP sur l'appel vers la ressource. 
 + 
 +===== Prérequis d'exploitation ===== 
 +Pour exploiter cette vulnérabilité, il est nécessaire d’avoir accès à une application qui ne filtre pas correctement les méthodes HTTP autorisées. 
 + 
 +==== Connaissances nécessaires ==== 
 +  * Connaissance de base du fonctionnement du protocole HTTP ; 
 +  * Maîtrise de la notion de méthode HTTP.
  
 ==== Outils nécessaires ==== ==== Outils nécessaires ====
  
-  * Des outils d'analyse de logs tels que Splunk, ELK Stack (Elasticsearch, Logstash, Kibana) ou encore Graylog peuvent grandement faciliter l'analyse, bien qu'il soit possible d'effectuer une analyse de base sans outils spécifiques ; +  * Outils de modification et/ou d’interception de requêtes (Burp, Curl).
-  * Un éditeur de texte avancé ou un outil capable de traiter de grands volumes de données textuelles peut également être utile.+
  
 ===== Flux d'exécution ===== ===== Flux d'exécution =====
Ligne 26: Ligne 65:
 ==== Explorer ==== ==== Explorer ====
  
-Collecter des données de log à partir de différentes sources comme les serveurs, les routeurs, les firewalls et les postes informatiques. Il est important de s'assurer que les données de log soient complètes, intègrent et couvrent la période d'intérêt, car elles constitueront la base de l'analyse.+Naviguer sur l’application pour récupérer les endpoints et/ou pages de l’application pour en déterminer les méthodes HTTP utilisées pour l'accès, la modification, la création et la suppression des données.
  
 ==== Expérimenter ==== ==== Expérimenter ====
  
-Analyser les données de log collectées pour trouver des indices pertinents en utilisant, soit une approche manuelle, soit des outils d'analyse automatisés. L'analyse peut inclure la recherche de motifs d'attaques connus, de comportements anormaux, la reconstruction de séquences d'événements et l'identification des acteurs malveillants. +Pour chacune des requêtes identifiées, envoyer la même requête, mais en utilisant une méthode différente. L'objectif ici est de potentiellement remarquer un comportement particulier de l'application.
- +
-Par exemple, lors de l'analyse des logs d'une application web sur un serveur Apache, pour comprendre une attaque récente, cherchez des modèles d'attaques connus, des **adresses IP** suspectes ou des **User-Agent** ayant effectué un nombre anormalement élevé de requêtes sur une courte période.+
  
 ==== Exploiter ==== ==== Exploiter ====
  
-Consultez les solutions de chaque challenge. 
  
-===== Bénéfices potentiels =====+===== Conséquences potentielles =====
  
-L'analyse de logs peut permettre : +Une exploitation réussie de ce type de vulnérabilité peut permettre : 
-  * La découverte de failles de sécurité ; +  * Le contournement de certains mécanismes de contrôle d'accès ; 
-  * L'identification d'acteurs malveillants et de leurs méthodes d'attaque ; +  * L'accès à des ressources sensibles et/ou à un espace privé de l'application.
-  * La compréhension des impacts d'une attaque ou d'une défaillance sur un système.+
  
-===== Prérequis =====+===== Contre-mesures =====
  
-Les prérequis suivants peuvent permettre de faciliter l'analyse de logs : +Les contre-mesures suivantes peuvent être mises en œuvre : 
-  * Mettre en place et appliquer une politique de journalisation adaptée au exigences légales et réglementaires ; +  * Configurer le serveur web pour n'autoriser que les méthodes HTTP que vous souhaitez utiliser. Par exemple, autoriser uniquement les méthodes GET et POST et bloquer les autres méthodes ; 
-  * Utiliser des outils de surveillance et d'analyse de logs en temps réel.+  * Utiliser des contrôles d'accès basés sur les rôles et les autorisations pour limiter l'accès aux différentes ressources et fonctionnalités de votre application ; 
 +  * Utiliser un pare-feu applicatif pour bloquer les requêtes HTTP non autorisées ou suspectes.
  
-====== Exemple de mise en ouvre ======+====== 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 ===== ===== Exemple 1 =====
  
 +Voici une configuration Apache potentiellement vulnérable aux modifications de méthodes HTTP :
  
-Voici un exemple de logs Apache qui pourraient indiquer une tentative d'**injection SQL** : +<code apache> 
- +<Directory /var/www/html> 
-<code class="apache"> +    AllowOverride None 
-127.0.0.1 - - [21/Jan/2022:10:00:00 +0000] "GET /index.php?id=1' OR '1'='1 HTTP/1.1" 200 612 +    Require all granted 
-127.0.0.1 - - [21/Jan/2022:10:00:01 +0000] "GET /index.php?id=1' OR '1'='2 HTTP/1.1" 500 612 +</Directory>
-127.0.0.1 - - [21/Jan/2022:10:00:02 +0000] "GET /index.php?id=1'; DROP TABLE users; -- HTTP/1.1" 500 612+
 </code> </code>
  
-Dans cet exemple, trois requêtes HTTP distinctes sont envoyées au serveur Apache. +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.
  
-  * La première requête contient une chaîne de caractères +Voici une nouvelle version de la configuration Apache :
  
-<code> +<code apache> 
-1' OR '1'='1+<Directory /var/www/html> 
 +    AllowOverride None 
 +    <Limit GET POST> 
 +        Require all granted 
 +    </Limit> 
 +</Directory>
 </code> </code>
  
-dans le paramètre **id**. Cette chaîne est souvent utilisée par les attaquants pour tester la vulnérabilité SQL Injection. Si la requête renvoie un code de retour HTTP 200 (succès), cela peut indiquer que l'injection SQL est possible.+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.
  
-  * La deuxième requête, avec la chaîne +===== Exemple 2 =====
  
-<code> 
-1' OR '1'='2 
-</code> 
  
-, est une autre tentative d'injection, visant à vérifier la réaction du serveur. Un code de retour **HTTP 500** (erreur interne du serveur) peut suggérer que l'injection SQL n'a pas réussi ou que le serveur a rencontré une erreur.+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 :
  
-  * La troisième requête est une tentative d'exploitation plus malveillante, visant à supprimer une table de la base de données. Encore une fois, un code de retour **HTTP 500** peut indiquer une erreur ou un blocage par des mesures de sécurité.+<code shell>
  
-===== Exemple 2 =====+$ 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 :
  
-Voici un exemple de logs Nginx qui pourraient indiquer une tentative d'attaque de type **LFI (Local File Inclusion)**:+<code shell>
  
-<code class="nginx"> +$ curl -X POST vulnerable.org/api/v1//user/5678/info -i 
-127.0.0.1 - - [21/Jan/2022:10:00:00 +0000] "GET /index.php?file=../../../etc/passwd HTTP/1.1" 403 612 +> < HTTP/2 200 
-127.0.0.1 - - [21/Jan/2022:10:00:01 +0000] "GET /index.php?file=../../../var/log/nginx/access.log HTTP/1.1" 403 612+> [...] 
 +> username: victim 
 +> [...]
 </code> </code>
  
-Dans cet exemple, deux requêtes HTTP sont envoyées au serveur Nginx.  +====== CWEs ====== 
-  * La première requête tente d'accéder au fichier **/etc/passwd** du système, ce qui est une tentative commune d'inclusion de fichier local. Si la requête renvoie un code de retour **HTTP 403** (accès interdit), cela indique que des mesures de sécurité peuvent être en place pour bloquer l'accès aux fichiers sensibles. +  * [[https://cwe.mitre.org/data/definitions/650.html|CWE-650 : Trusting HTTP Permission Methods on the Server Side]] 
-  * La deuxième requête tente d'accéder au fichier de logs d'accès de Nginx. Un code de retour **HTTP 403** indique également que l'attaque LFI n'a pas réussi en raison des restrictions d'accès. +    * 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 :  +====== References ======
-  * https://openclassrooms.com/fr/courses/1750566-optimisez-la-securite-informatique-grace-au-monitoring/7144422-selectionnez-les-logs-a-analyser +
-  * https://www.ssi.gouv.fr/uploads/2022/01/anssi-guide-recommandations_securite_architecture_systeme_journalisation.pdf +
-  * https://www.ssi.gouv.fr/uploads/2022/01/anssi-guide-recommandations_securite_journalisation_systemes_microsoft_windows_environnement_active_directory.pdf +
-  * https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf+
  
 +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 ====== ====== Retour fiches vulnérabilités ======
   * [[cyber:vulnerabilite:accueil|Cyber fiches vulnérabilités]]   * [[cyber:vulnerabilite:accueil|Cyber fiches vulnérabilités]]
  
  
cyber/vulnerabilite/http_methods.1752240068.txt.gz · Dernière modification : 2025/07/11 15:21 de admin