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

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 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)  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  déclenche une requête GET ; les données de formulaire envoyées par   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. 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.
 * 1) !/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

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