De nombreux scanners de sécurité comme nikto , nessus , nmap et w3af montrent parfois que certaines méthodes HTTP comme HEAD, GET , POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, etc. sont vulnérables aux attaques.
Que font ces en-têtes et comment peuvent-ils être exploités?
Je recherche quelque chose de plus créatif que les exploits courants comme POST ou GET injections (par exemple, champs modifiés). Cela m'aiderait à comprendre si votre réponse me montrait un bref exemple de l'utilisation normale de l'en-tête par rapport à une technique d'exploitation d'un en-tête.
Certaines de ces méthodes sont généralement dangereuses à exposer, et certaines sont tout simplement étrangères dans un environnement de production, ce qui pourrait être considéré comme une surface d'attaque supplémentaire. Néanmoins, cela vaut la peine de les fermer également, car vous n'en aurez probablement pas besoin:
PUT, DELETE - comme mentionné par @Justin, ces méthodes étaient initialement conçues comme des opérations de gestion de fichiers.
Certains serveurs Web les prennent toujours en charge dans leur format d'origine. Autrement dit, vous pouvez modifier ou supprimer des fichiers du système de fichiers du serveur, arbitrairement. Évidemment, si ceux-ci sont activés, cela vous ouvre à des attaques dangereuses.
Les autorisations d'accès aux fichiers doivent être très strictement limitées, si vous DEVEZ absolument avoir ces méthodes activées. Mais vous ne devriez pas, de toute façon - de nos jours, il existe des scripts simples que vous pouvez utiliser (s'il s'agit d'un site Web statique - s'il s'agit d'une application réelle, codez-le vous-même) pour prendre en charge cette fonctionnalité si vous en avez besoin.
REMARQUE: Un scénario valide pour activer ces méthodes (PUT et DELETE) est si vous développez une API ou un service strictement RESTful ; cependant, dans ce cas, la méthode serait gérée par votre code d'application et non par le serveur Web.
OPTIONS - il s'agit d'une méthode de diagnostic, qui renvoie un message utile principalement pour le débogage et autres. Ce message indique essentiellement, de manière surprenante, quelles méthodes HTTP sont actives sur le serveur Web. En réalité, il est rarement utilisé de nos jours à des fins légitimes, mais il accorde à un attaquant potentiel un peu peu d'aide: il peut être considéré comme un raccourci pour trouver un autre trou.
Maintenant, ce n'est pas vraiment une vulnérabilité en soi; mais comme il n'y a aucune utilité réelle, cela affecte simplement votre surface d'attaque et devrait idéalement être désactivé.
REMARQUE: Malgré ce qui précède, la méthode OPTIONS IS utilisée à plusieurs fins légitimes de nos jours, par exemple certaines REST nécessitent une demande OPTIONS, CORS nécessite des demandes de pré-vol, etc. Il y a donc certainement des scénarios dans lesquels les OPTIONS doivent être activées, mais la valeur par défaut doit toujours être "désactivée sauf si nécessaire".
TRACE - c'est la surprise ... Encore une fois, une méthode de diagnostic (comme @Jeff l'a mentionné), qui retourne dans le corps de la réponse, la requête HTTP entière. Cela inclut le corps de la demande, mais aussi les en-têtes de demande, y compris par exemple cookies, en-têtes d'autorisation, etc.
Pas trop surprenant, cela peut être considérablement mal utilisé, comme l'attaque classique Cross-Site Tracing (XST) , dans laquelle un vecteur XSS peut être utilisé pour récupérer HttpOnly cookies, en-têtes d'autorisation, etc. Cela devrait certainement être désactivé.
Un autre ensemble de méthodes mérite de mentionner: TOUS LES AUTRES . Pour certains serveurs Web, afin d'activer/désactiver/restreindre certaines méthodes HTTP, vous les définissez explicitement d'une manière ou d'une autre dans le fichier de configuration. Cependant, si aucune valeur par défaut n'est définie, il peut être possible "d'injecter" des méthodes supplémentaires, en contournant certains contrôles d'accès que le serveur Web peut avoir mis en œuvre (mal). Voir par exemple quelques informations supplémentaires sur OWASP .
En utilisant la méthode PUT, vous pouvez télécharger n'importe quel fichier sur le serveur. Cela peut être utilisé pour effectuer des Cross Site Scripting (XSS). Aujourd'hui, j'ai effectué cette attaque, répondant donc ici avec mon expérience. La procédure à suivre est expliquée ci-dessous.
PUT /XSS.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.myblog.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
(Input your XSS script here)
Le serveur répond en retour avec un code d'état 201 qui dit "le fichier a été créé avec succès".
HTTP/1.1 201 Created
Date: Mon, 05 May 2014 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed
Nous pouvons maintenant essayer d'accéder à ce fichier XSS.html téléchargé dans le navigateur. Dès que vous accédez à cette page, vous obtenez une fenêtre contextuelle XSS.
De même, cela peut être exploité davantage pour effectuer l'injection de commande, bien que je n'aie pas encore essayé cela. Si l'application utilise XML, l'attaque d'entité externe XML peut également être effectuée. Je ne l'ai pas encore fait. L'attaque transversale de l'annuaire peut également être possible.
Le principal avertissement concernant TRACE est qu'il est conçu pour séparer le routage d'une demande HTTP, de la même manière que traceroute est censé séparer le routage d'un paquet. La principale différence est que la commande TRACE implique des opérations sur le backend et la divulgation de ce qui a été reçu. Cela pourrait être un problème si votre frontal fournit des clés API ou quelque chose de similaire à votre backend.
Consultez RFC 2616 pour plus d'informations sur TRACE ainsi que des explications sur les autres en-têtes.