4.8.3 Test d'HTTP Verb Tampering (OTG-INPVAL-003)

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

La spécification de HTTP comprend des méthodes de requêtes autres que les classiques GET et POST. Un serveur HTTP conforme aux standards peut répondre à ces méthodes alternatives d'une façon non prévu par les développeurs. Bien que la description usuelle soit falsification de 'verbe', le standard HTTP 1.1 nomme ces types de requêtes des 'méthodes'.

La spécification complète de HTTP 1.1 [1] dfinit les méthodes (ou verbe) de requêtes HTTP valides suivantes :

OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT

Si elles sont activées, les extensions WebDAV (Web Distributed Authoring and Version) [2] [3] permettent plusieurs autres méthodes HTTP :

PROPFIND
PROPPATCH
MKCOL
COPY
MOVE
LOCK
UNLOCK

Cependant, la plupart des applications web n'ont besoin de répondre qu'aux requêtes GET et POST, respectivement en fournissant des données utilisateur dans la chaîne de la requête URL ou en les ajoutant à la requête. Le code standard <a href=""></a> déclenche une requête GET ; les données de formulaire envoyées par <form method='POST'></form> déclencheront une requête POST. Les formulaires définits sans méthode seront envoyés par GET par défaut.

Bizarrement les autres méthodes HTTP valides ne sont pas supportées par le standard HTML [4]. Toute autre méthode HTTP que GET ou POST doit être appelée en dehors du document HTML. Cependant, des appels JavaScript et AJAX peuvent appeler d'autres méthodes que GET et POST.

Tant que l'application web à tester n'appelle pas spécifiquement des méthodes HTTP non standard, tester la falsification de verbe HTTP est très simple. Si le serveur accepte d'autres types de requêtes que GET ou POST, le test échoue. Les solutions sont de désactiver toutes les fonctionnalités autre que GET et POST dans le serveur applicatif, ou sur le pare-feu applicatif web.

Si des méthodes telles que HEAD ou OPTIONS sont requise pour votre application, cela accroit la surface de manière importante. Chaque action dans le système doit être testée pour vérifier que ces méthodes ne déclenchent pas d'actions sans authentification correcte ni ne révèlent des informations sur le contenu ou le fonctionnement de l'application. So possible, il faut limiter l'utilisation de ces méthodes HTTP alternatives à une seule page ne contenant aucune action utilisateur, comme la page par défaut (index.html, par exemple).

Comment tester

Comme le standard HTML ne supporte pas de méthodes de requêtes autres que GET et POST, il faut construire des requêtes HTTP spécifiques d'une autre manière. Il est fortement recommandé d'utiliser des outils pour cela, bien que nous allons aussi démontrer comment le faire manuellement.

Test manuel de falsification de verbe HTTP

Cet exemple est écrit en utilisant le paquetage netcat d'openbsd (inclus en standard dans la plupart des distributions Linux). Vous pouvez également utiliser telnet (inclus dans Windows) de manière similaire.

1. Construire des requêtes HTTP spécifiques

Chaque requête HTTP 1.1 se conforme au formatage et à la syntaxe suivante. Des éléments entourés par des chevrons [ ] sont contextuels à l'application. La ligne vide à la fin est obligatoire.

[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]

Pour construire des requêtes séparées, vous pouvez saisir manuellement chaque requête dans netcat ou telnet et examiner la réponse. Cependant, il est plus rapide de stocker chaque requête dans un fichier séparé. Cette seconde approche est celle que nous allons appliquer dans ces exemples. Utilisez votre éditeur de texte favori pour créer un fichier texte pour chaque méthode. Modifiez les requêtes pour les adapter à la page par défaut de votre application et domaine.

1.1 OPTIONS

OPTIONS /index.html HTTP/1.1
host: www.example.com

1.2 GET

GET /index.html HTTP/1.1
host: www.example.com

1.3 HEAD

HEAD /index.html HTTP/1.1
host: www.example.com

1.4 POST

POST /index.html HTTP/1.1
host: www.example.com

1.5 PUT

PUT /index.html HTTP/1.1
host: www.example.com

1.6 DELETE

DELETE /index.html HTTP/1.1
host: www.example.com

1.7 TRACE

TRACE /index.html HTTP/1.1
host: www.example.com

1.8 CONNECT

CONNECT /index.html HTTP/1.1
host: www.example.com

2. Envoyer des requêtes HTTP

Pour chaque méthode et/ou fichier texte, envoyez la requête vers votre serveur web via netcat ou telnet sur le port 80 (HTTP) :

nc www.example.com 80 < OPTIONS.http.txt

3. Analyser les réponses HTTP

Bien que chaque réponse HTTP puisse renvoyer des résultats différents, il n'y a qu'un seul résultat valide pour toutes les méthodes autres que GET et POST. Le serveur web devrait ignorer complètement la requête ou retourner une erreur. Toute autre réponse indique un échec du test, puisque le serveur répond à des méthodes/verbes inutiles. Ces méthodes doivent être désactivées.

Un exemple d'échec (c'est-à-dire que le serveur supporte OPTIONS alors que c'est inutile) :

Test automatisé de falsification de verbe HTTP

Si vous pouvez analyser votre application simplement via les codes de retour HTTP (200 OK, 501 Error, etc.), Alors le script suivant va tester toutes les méthodes HTTP disponibles.

#!/bin/bash

for webservmethod in GET POST PUT TRACE CONNECT OPTIONS PROPFIND;

do
printf "$webservmethod " ;
printf "$webservmethod / HTTP/1.1\nHost: $1\n\n" | nc -q 1 $1 80 | grep "HTTP/1.1"

done

Code copié du blog Lab de Tests d'Intrusion [5]

Références

Whitepapers

• Arshan Dabirsiaghi: “Bypassing URL Authentication and Authorization with HTTP Verb Tampering” - http://www.aspectsecurity.com/research-presentations/bypassing-vbaac-with-http-verb-tampering