HTTP offre un certain nombre de méthodes qui peuvent être utilisées pour effectuer des actions sur un serveur Web. Beaucoup de ces méthodes sont conçues pour aider les développeurs à déployer et tester des applications HTTP. Ces méthodes HTTP peuvent être utilisé à des fins malveillantes si le serveur web est mal configuré. En outre, l'attaque Cross Site Tracing (XST), est une forme de cross site scripting en utilisant la méthode du serveur HTTP TRACE.

GET et POST sont de loin les méthodes les plus courantes qui sont utilisées pour accéder aux informations fournies par un serveur web, le Hypertext Transfer Protocol (HTTP) permet plusieurs autres (un peu moins connues) méthodes. RFC 2616 (qui décrit la version HTTP 1.1 qui est la norme aujourd'hui) définit les huit méthodes suivantes:

*HEAD 
*GET 
*POST 
*PUT 
*DELETE 
*TRACE 
*OPTIONS 
*CONNECT 

Certaines de ces méthodes peuvent potentiellement poser un risque de sécurité pour une application web, car elles permettent à un attaquant de modifier les fichiers stockés sur le serveur Web et, dans certains scénarios, de voler les informations d'identification des utilisateurs légitimes. Plus précisément, les méthodes qui doivent être désactivés sont les suivants:

• PUT: Cette méthode permet au client de télécharger de nouveaux fichiers sur le serveur Web. Un attaquant peut l'exploiter en téléchargeant des fichiers malveillants (par exemple: un fichier ASP qui exécute les commandes en invoquant cmd.exe), ou simplement en utilisant le serveur de la victime comme un référentiel de fichiers
• DELETE: Cette méthode permet à un client de supprimer un fichier sur le serveur Web. Un attaquant peut l'exploiter comme un moyen très simple et direct de défigurer un site Web ou de lancer une attaque DoS
• CONNECT: Cette méthode pourrait permettre à un client d'utiliser le serveur Web comme un proxy
• TRACE: Cette méthode simple fait écho au client quel que soit la chaîne envoyée au serveur, et est utilisé principalement à des fins de débogage. Cette méthode, initialement supposée inoffensive, peut être utilisée pour monter une attaque connue sous le nom de Cross Site Tracing, qui a été découverte par Jeremiah Grossman (voir liens en bas de la page)

Si une application a besoin d'une ou de plusieurs de ces méthodes, telles que les services Web REST (qui peuvent nécessiter PUT ou DELETE), il est important de vérifier que leur utilisation est limitée à des utilisateurs de confiance et dans des conditions de sécurité suffisantes.

Arshan Dabirsiaghi (voir les liens) a découvert que de nombreux frameworks d'application Web autorisent l'utilisation de méthodes HTTP choisies et / ou arbitraires pour contourner les contrôles d'accès d'un environnement:

Plusieurs frameworks et des langues traitent “HEAD” comme un “GET”, quoique sans corps dans la réponse. Si une contrainte de sécurité a été mise sur «Get» n'autorisant de telles demandes que pour les seuls «AuthenticatedUsers“ pour un servlet particulier ou une ressource, cela pourrait être contourné en utilisant la méthode “HEAD”. Cela permet la soumission aveugle non autorisée de toute requête GET Certains frameworks permettent les méthodes HTTP arbitraires telles que «JEFF» ou «CATS» sans limitation. Ceux-ci sont traités comme une méthode “GET”, et ne sont pas soumis aux contrôles d'accès liés au langages et aux frameworks, permettant là encore soumission aveugle non autorisée de requêtes privilégiées GET.

Dans de nombreux cas, le code qui explicitement vérifie une méthode “POST” “GET” serait en sécurité.

Pour effectuer ce test, nous avons besoin d'un moyen pour savoir quelles méthodes HTTP sont supportées par le serveur Web que nous examinons. La méthode OPTIONS HTTP nous fournit le moyen le plus direct et efficace de le faire. La RFC 2616 stipule que «La méthode OPTIONS représente une demande d'informations sur les options de communication disponibles sur la chaîne de requête / réponse identifiée par l'URI de la demande.

La méthode de test est extrêmement simple et il suffit d'utiliser netcat (ou telnet):

icesurfer@nightblade ~ $ nc www.victim.com 80 
OPTIONS / HTTP/1.1
Host: www.victim.com
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0
icesurfer@nightblade ~ $ 

Comme nous pouvons le voir dans l'exemple, OPTIONS fournit une liste des méthodes prises en charge par le serveur web, et dans ce cas nous pouvons voir, par exemple, que la méthode TRACE est activée. Le danger qui est posé par cette méthode est illustrée dans la section suivante

Remarque: afin de comprendre la logique et les objectifs de cette attaque, vous devez être familier avec les attaques multisites par scripts.

La méthode TRACE, bien qu'apparemment inoffensive, peut être utilisée avec succès en effet de levier dans certains scénarios permettant de voler les informations d'identification des utilisateurs légitimes. Cette technique d'attaque a été découverte par Jeremiah Grossman en 2003, dans une tentative de contourner la balise HTTPOnly que Microsoft a introduite dans Internet Explorer 6 SP1 pour protéger les cookies de JavaScript. L'un des schémas d'attaque les plus récurrents dans les Cross Site Scripting est d'accéder à l'objet document.cookie et d'envoyer à un serveur web contrôlé par l'attaquant pour qu'il / elle puisse détourner la session de la victime. Le marquage d'un cookie par httpOnly interdit JavaScript d'y accéder, pour l'empêcher d'être envoyé à un tiers. Cependant, la méthode TRACE peut être utilisée pour contourner cette protection et accéder au cookie, même dans ce scénario.

Comme mentionné précédemment, TRACE renvoie simplement une chaîne de caractères qui est envoyée au serveur Web. Afin de vérifier la présence (ou de vérifier les résultats des options de demande ci-dessus), on peut procéder comme indiqué dans l'exemple suivant:

icesurfer@nightblade ~ $ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39 
...
TRACE / HTTP/1.1
Host: www.victim.com

Comme nous pouvons le voir, le corps de la réponse est exactement une copie de notre demande initiale, ce qui signifie que notre objectif permet cette méthode. Si nous indiquons à un navigateur d'émettre une requête TRACE au serveur web, et que ce navigateur possède un cookie pour ce domaine, le cookie sera automatiquement inclus dans les en-têtes de demande, et sera donc renvoyée en écho dans la réponse obtenue. À ce moment, la chaîne de cookie sera accessible par JavaScript et il sera enfin possible de l'envoyer à un tiers, même lorsque le cookie est étiqueté comme httpOnly.

Il y a plusieurs façons de faire d'un navigateur une produise une demande TRACE, tels que le contrôle ActiveX XMLHTTP dans Internet Explorer et XMLDOM dans Mozilla et Netscape. Cependant, pour des raisons de sécurité un navigateur est autorisé à démarrer un seul lien avec le domaine où réside le script hostile. Il s'agit d'une circonstance atténuante, car l'attaquant doit combiner la méthode TRACE avec une autre vulnérabilité pour monter l'attaque.

Fondamentalement, un attaquant a deux façons de lancer avec succès une attaque de type Cross Site Tracing:

• Tirer parti d'une autre vulnérabilité côté serveur: l'attaquant injecte l'extrait hostile JavaScript qui contient la requête TRACE dans l'application vulnérable, comme dans une attaque normale Cross Site Scripting
• Miser sur une vulnérabilité côté client: l'attaquant crée un site Web malveillant qui contient le code JavaScript hostile et exploite une vulnérabilité inter-domaines du navigateur de la victime, afin d'exécuter le code JavaScript avec succès par une connexion au site qui prend en charge la méthode TRACE et qui a délivré le cookie que l'attaquant essaie de voler.

Des informations plus détaillées, avec des exemples de code, peuvent être trouvés dans le livre blanc original écrit par Jeremiah Grossman.

Le test par altération des méthodes HTTP est essentiellement la même que les essais XST.

Trouver une page que vous souhaitez visiter qui a une contrainte de sécurité telle qu'il ne serait normalement pas possible de forcer une redirection « 302 » vers une page de connexion ou forcer une connexion directe. L'URL de test dans cet exemple fonctionne comme ceci - comme le font beaucoup d'applications web. Toutefois, si vous obtenez une réponse “200” qui n'est pas une page de connexion, il est possible de contourner l'authentification et ainsi l'autorisation.

[rapidoffenseunit:~] vanderaj% nc www.example.com 80
JEFF / HTTP/1.1
Host: www.example.com
...
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:38:40 GMT
Server: Apache
Set-Cookie: PHPSESSID=K53QW...

Si votre framework ou pare-feu ou application ne supporte pas la méthode “JEFF”, il/elle devrait publier une page d'erreur (ou de préférence une page d'erreur 405 Non admis ou 501 Non implémenté). Si il/elle honore la demande, il/elle est vulnérable à ce problème.

Si vous sentez que le système est vulnérable à ce problème, tentez des attaques de type CSRF pour approfondir l'étude de la faille plus en détail:

• FOOBAR /admin/createUser.php?member=myAdmin

  • JEFF /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
  • CATS /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

  Avec un peu de chance, en utilisant les trois commandes ci-dessus - modifiées pour s'adapter à l'application en cours de test - un nouvel utilisateur sera créé, un mot de passe luis sera attribué et il sera élevé au rang d'admin.

Trouver une page que vous souhaitez visiter qui a une contrainte de sécurité telle qu'il ne serait normalement pas possible de forcer une redirection « 302 » vers une page de connexion ou forcer une connexion directe. L'URL de test dans cet exemple fonctionne comme ceci - comme le font beaucoup d'applications web. Toutefois, si vous obtenez une réponse “200” qui n'est pas une page de connexion, il est possible de contourner l'authentification et ainsi l'autorisation.

[rapidoffenseunit:~] vanderaj% nc www.example.com 80
HEAD /admin HTTP/1.1
Host: www.example.com
...
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com
Content-Language: EN
Connection: close
Content-Type: text/html; charset=ISO-8859-1

Si vous obtenez un “405 Méthode non autorisée” ou “501 Méthode non implémentée”, l'application / framework / language / system / pare-feu fonctionne correctement. Si un réponse code “200” revient, et la réponse ne contient pas de corps, il est probable que l'application ait traiter la demande sans authentification ou d'autorisation et d'autres tests sont nécessaires.

Si vous sentez que le système est vulnérable à ce problème, tentez des attaques de type CSRF pour approfondir l'étude de la faille plus en détail:

• HEAD /admin/createUser.php?member=myAdmin

  • HEAD /admin/changePw.php?member=myAdmin&passwd=foo123&confirm=foo123
  • HEAD /admin/groupEdit.php?group=Admins&member=myAdmin&action=add

  Avec un peu de chance, en utilisant les trois commandes ci-dessus - modifiées pour s'adapter à l'application en cours de test - un nouvel utilisateur sera créé, un mot de passe lui sera attribué, et il sera fait admin.

Suivre les mêmes étapes d'un scénario de Black Box.

• RFC 2616: Hypertext Transfer Protocol – HTTP/1.1
• RFC 2109 and RFC 2965: HTTP State Management Mechanism
• Jeremiah Grossman: “Cross Site Tracing (XST)” - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
• Amit Klein: “XS(T) attack variants which can, in some cases, eliminate the need for TRACE” - http://www.securityfocus.com/archive/107/308433

  • Arshan Dabirsiaghi: “Bypassing VBAAC with HTTP Verb Tampering” - http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf

• NetCat - http://nc110.sourceforge.net