This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

4.3.6 Test des Methodes HTTP (OTG-CONFIG-006)

From OWASP
Jump to: navigation, search 
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

Résumé

HTTP propose plusieurs méthodes pour réaliser des actions sur le serveur web. Plusieurs de ces méthodes sont prévues pour aider le développeur à déployer et à tester les applications HTTP. Si le serveur est mal configuré, ces méthodes HTTP peuvent être utilisées dans des buts malveillants. On examinera aussi le Cross Site Tracing (XST), une sorte d’attaque de type Cross Site Scripting (XSS) qui utilise la méthode HTTP TRACE.
Bien que GET et POST soient, de loin, les méthodes les plus employées pour accéder aux informations des serveurs web, HTTP en permet plusieurs autres moins connues. La version HTTP/1.1, qui est le standard actuel, est décrite par le RFC 2616 (ou, les RFC 723x depuis 2014). En particulier, le RFC 7231 décrit les huit méthodes suivantes :

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

Certaines de ces méthodes présentent des risques pour les applications web car elles permettent à un attaquant de modifier des fichiers stockés sur le serveur web et, dans certains scénarios, de voler des justificatifs d’accès d’utilisateurs légitimes. En particulier, les méthodes, qui devraient être désactivées, sont les suivantes :

  • PUT: Cette méthode permet à un client de charger un nouveau fichier sur le serveur web. Un attaquant peut l’exploiter pour charger du contenu malveillant (ex. un fichier .asp qui exécute une commande en lançant cmd.exe) ou, simplement en utilisant le serveur de la victime comme un dépôt de fichiers.
  • DELETE: Cette méthode permet à un client de supprimer un fichier sur le serveur web. Un attaquant peut l’exploiter comme moyen simple et direct pour défigurer un site web ou concevoir une attaque de Déni de Service-DoS.
  • CONNECT: Cette méthode peut permettre à un client d’utiliser un serveur web comme proxy.
  • TRACE: Cette méthode renvoie en écho au client toute chaîne qui a été envoyée au serveur et est utilisée principalement pour du débogage. Cette méthode, supposée à l’origine être inoffensive, peut être utilisée pour préparer une attaque de type “Cross Site Tracing”, attaque découverte par Jeremiah Grossman (voir le lien en bas de page).

Si une application a besoin d’au moins une de ces méthodes, comme les services Web REST (qui peuvent nécessiter PUT ou DELETE), il est important de vérifier que l’utilisation qui en est faite est correctement limitée à des utilisateurs approuvés et effectuée dans un environnement sûr.

Méthodes HTTP arbitraires

Arshan Dabirsiaghi (voir les liens) a découvert que beaucoup de frameworks d’applications web permettent d’utiliser des méthodes HTTP ciblées ou arbitraires pour contourner l’environnement de vérification de contrôle d’accès :

  • Beaucoup de frameworks et de langages gèrent la méthode "HEAD" comme une requête "GET", bien que la réponse à la requête "HEAD" ne devrait pas contenir de corps de message. Ainsi, si on a mis en place une contrainte de sécurité sur les requêtes "GET" telle que, seuls les utilisateurs authentifiés peuvent accéder à une servlet ou à une ressource particulière, cette contrainte sera contournée dans l’appel à la méthode "HEAD". Cela permet, à l’aveugle et sans autorisation, d’accéder à toute requête "GET" privilégiée.
  • Certains frameworks autorisent que des méthodes HTTP arbitraires telles que "JEFF" ou "CATS" soient utilisées sans aucune limitation. Celles-ci sont traitées comme des méthodes "GET" et se trouvent, dans certains langages et frameworks, ne pas être soumises aux vérifications d’accès fondées sur les rôles des méthodes standard, permettant, une fois encore, un accès, à l’aveugle et sans autorisation, à des ressources "GET" privilégiées.

Dans bien des cas, le code qui vérifiera explicitement que la méthode est un "GET" ou un "POST", sera sûr.

Comment Tester

Découvrir les Méthodes Supportées
Pour réaliser ce test, le testeur devra savoir quelles méthodes HTTP sont supportées par le serveur à évaluer. La méthode HTTP "OPTIONS" donne au testeur un moyen direct et efficace pour le faire. Le RFC 2616 indique ainsi que «La méthode "OPTIONS" est une demande d’information sur les options de communications supportées dans la séquence des requêtes/réponses déterminées par l’URI de la requête.» La méthode de test est très simple et une commande netcat (ou telnet) suffit : 

$ 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

Comme on peut le voir dans cet exemple, OPTIONS renvoie la liste des méthodes supportées par le serveur web, et on remarque ici que la méthode "TRACE" est activée. Le danger, que cela représente, est illustré dans la section suivante.

Test de vulnérabilité XST
Note: pour bien comprendre la logique et le but de l’attaque XST, il faut être familier des attaques de type Cross Site Scripting (XSS). La méthode "TRACE", apparemment inoffensive, peut être utilisée dans certains scénarios pour voler des justificatifs d’accès d’utilisateurs légitimes. Cette technique d’attaque a été découverte par Jeremiah Grossman en 2003, dans une tentative de contournement de la balise HTTPOnly que Microsoft a introduite dans Internet Explorer 6 SP1 pour empêcher Javascript d’accéder aux cookies. En effet, l’un des motifs récurrents d’attaques de type XSS (Cross Site Scripting) concerne l’accès à l’objet document.cookie qui est renvoyé à un serveur web contrôlé par l’attaquant pour qu’il puisse détourner la session de la victime. Marquer un cookie avec l’attribut HTTPOnly interdit à Javascript d’y accéder, le protégeant ainsi d’un envoi à une partie tierce. Malgré cela, même dans ce cas, la méthode "TRACE" peut être utilisée pour contourner cette protection et accéder aux cookies. Comme indiqué précédemment, TRACE renvoie simplement chaque chaîne de caractères envoyée au serveur web. Pour vérifier sa présence sur le serveur (ou confirmer les résultats de la requête OPTIONS précédente), le testeur peut effectuer la commande suivante : 

$ 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

Le corps de la réponse est une copie exacte de notre requête initiale, ce qui signifie que la cible accepte la méthode "TRACE". Alors, où se cache le danger ? Si le testeur indique au navigateur d’envoyer une requête TRACE au serveur web et si le navigateur a un cookie pour ce domaine, ce cookie sera automatiquement inclus dans les entêtes de requêtes et donc renvoyé en écho dans la réponse. A partir de là, la chaîne représentant le cookie sera accessible par JavaScript et, il sera finalement possible de l’envoyer à une partie tierce, même s’il a l’attribut HTTPOnly.

Il y a différents moyens pour qu’un navigateur envoie une requête "TRACE", en particulier, il y a le contrôle ActiveX XMLHttpRequest dans Internet Explorer et XMLDOM dans Mozilla. Quoiqu’il en soit, pour des raisons de sécurité, le navigateur ne peut initier une connexion que sur le domaine où se trouve le script malveillant. C’est un facteur qui en limite les possibilités car l’attaquant devra combiner la méthode "TRACE" avec une autre vulnérabilité pour réaliser cette attaque. Un attaquant a deux moyens de réussir une attaque de type Cross Site Tracing :

  • Profiter d’une autre vulnérabilité du serveur : l’attaquant injecte un code JavaScript malveillant, qui contient une requête "TRACE", dans l’application vulnérable comme pour une attaque standard de type XSS-Cross Site Scripting
  • Profiter d’une autre vulnérabilité du client : l’attaquant crée un site web malveillant qui contient le code JavaScript hostile et exploite une vulnérabilité inter-domaine du navigateur de la victime, de façon à ce que le code JavaScript réalise avec succès une connexion au site qui supporte la méthode "TRACE" et qui a généré le cookie que l’attaquant convoite.

Vous pourrez trouver plus d’informations, ainsi que des exemples de code, dans le document original de Jeremiah Grossman.

Note du traducteur : Depuis la divulgation de cette attaque, les navigateurs récents stoppent les requêtes "TRACE" effectuées via Javascript.

Test des Méthodes HTTP arbitraires

Chercher une page, avec une contrainte de sécurité qui devrait normalement conduire à une redirection "302" vers une page de connexion, ou à une connexion directe. L’URL de test de l’exemple fonctionne ainsi, comme beaucoup d’applications web. Néanmoins, si le testeur reçoit une réponse "200" qui n’est pas une page de connexion, il est possible de contourner l’authentification et donc les autorisations d’accès : $ 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 le framework, le pare-feu ou l’application ne prend pas en compte pas la méthode "JEFF", il devrait envoyer une page d’erreur (ou, mieux une page d’erreur indiquant "405 Not Allowed" ou "501 Not implemented"). S’il effectue la requête, il est vulnérable à ce problème. Si le testeur pense que le système est vulnérable à ce problème, il doit tenter une attaque de type CSRF (Falsification de requête intersites) pour l’exploiter au maximum :

  • 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 de la chance, en utilisant les trois commandes ci-dessus, -modifiées pour s’adapter à l’application et aux besoins du test- un nouvel utilisateur sera créé avec un mot de passe choisi et des droits administrateur.


Test de Contournement du contrôle d’accès de la requête HEAD

Chercher une page, avec une contrainte de sécurité qui devrait normalement conduire à une redirection "302" vers une page de connexion, ou à une connexion directe. L’URL de test de l’exemple fonctionne ainsi, comme beaucoup d’applications web. Néanmoins, si le testeur reçoit une réponse "200" qui n’est pas une page de connexion, il est possible de contourner l’authentification et donc les autorisations d’accès : 

$ 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 le testeur reçoit un "405 Method not allowed" ou un "501 Method Unimplemented", la cible (application / framework / langage / système / parefeu) fonctionne correctement. S’il reçoit un "200" en retour, et que la réponse ne contient pas de corps de message, c’est que l’application a accepté la requête sans effectuer de contrôle d’authentification et d’autorisation ce qui garantit de pouvoir effectuer des tests complémentaires.

Si le testeur pense que le système est vulnérable à ce problème, il doit tenter une attaque de type CSRF (falsification de requête intersites) pour l’exploiter au maximum :

  • 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 de la chance, en utilisant les trois commandes ci-dessus, -modifiées pour s’adapter à l’application et aux besoins du test- un nouvel utilisateur sera créé avec un mot de passe choisi et des droits administrateur, tout cela avec la soumission de requêtes à l’aveugle.

Outils

Références

Livres Blancs

Retrieved from "https://wiki.owasp.org/index.php?title=4.3.6_Test_des_Methodes_HTTP_(OTG-CONFIG-006)&oldid=202185"