Résumé

Dans ce chapitre, nous allons illustrer des exemples d'attaques que tirent profit de fonctionnalités spécifiques du protocole HTTP, que ce soit en exploitant les faiblesses de l'application Web ou des particularités dans la manière dont les agents interprètent les messages HTTP

Description

Nous allons analyser deux attaques différentes qui ciblent spécifiquement les en-têtes HTTP: HTTP splitting et HTTP smuggling.

La première attaque exploite un manque de désinfection de l'entrée qui permet d'insérer un CR / LF dans l'en-tête de la réponse provoquant un «split» de celle-ci en deux différents messages HTTP. L'objectif de l'attaque peut varier d'un empoisonnement du cache à du Cross Site Scripting.
Dans la seconde attaque, l'attaquant exploite le fait que certains messages HTTP spécialement conçus peuvent être analysées et interprétés de différentes manières en fonction de l'agent qui les reçoit. Cela exige un certain niveau de connaissances sur les différents agents qui manipulent les messages HTTP (serveur web, proxy, pare-feu) et par conséquent ne seront inclus que dans la section des tests boîte grise

Test Boîte Noire

HTTP Splitting

Certaines applications Web utilisent une partie de l'entrée de l'utilisateur pour générer les valeurs de certaines en-têtes de leurs réponses. L'exemple le plus simple est fourni par les redirections dans laquelle l'URL cible dépend de quelques valeurs soumisent par les utilisateurs. Disons par exemple que l'utilisateur est invité à choisir si il / elle préfère une interface Web standard ou avancé. Le choix sera passé comme un paramètre qui sera utilisé dans l'en-tête de réponse pour déclencher la redirection vers la page correspondante. Plus précisément, si le paramètre «interface» a la valeur «advanced» l'application répondra à ce qui suit:

HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced
<snip>

Lors de la réception de ce message, le navigateur va amener l'utilisateur à la page indiquée dans l'en-tête. Toutefois, si l'application ne filtre pas la saisie de l'utilisateur, il sera possible d'insérer dans le paramètre «interface» la séquence,%0d%0a ce qui représente la séquence CRLF qui est utilisée pour séparer les différentes lignes. À ce stade, nous serons en mesure de déclencher une réponse qui sera interprétée comme deux réponses différentes par toute agent qui arrive à l'analyser, par exemple un cache Web entre nous et l'application. Cela peut être exploité par un attaquant pour empoisonner le cache web afin qu'il fournisse du faux contenu dans toutes les demandes ultérieures. Disons que dans notre exemple précédent, le testeur transmet les données suivantes en tant que paramètre d'interface:

advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>

La réponse résultant de l'application vulnérable sera donc la suivante:

HTTP/1.1 302 Moved Temporarily
Date: Sun, 03 Dec 2005 16:22:19 GMT
Location: http://victim.com/main.jsp?interface=advanced
Content-Length: 0
...
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 35
*
<html>Sorry,%20System%20Down</html>
 <other data>

Le cache Web verra deux réponses différentes, donc si l'attaquant envoie, immédiatement après la première demande, une deuxième demande pour /index.html, le cache Web fera correspondre à cette demande la deuxième réponse et mettra en cache le contenu, de sorte que toutes les demandes ultérieures visant victim.com/index.html passant par la cache Web recevra le message“system down”. De cette manière, l'attaquant devrait être en mesure d'effectivement polluer le site pour que tous les utilisateurs qui utilisent ce cache web (tout Internet, si le cache Web est un reverse proxy de l'application Web). Alternativement, l'attaquant pourrait retourner à ces utilisateurs un extrait de code JavaScript qui provoquera une attaque de scriptage intersite, par exemple, pour voler les cookies. Notez que bien que la vulnérabilité se trouve dans l'application, l'objectif ici est ses utilisateurs.

Par conséquent, afin de rechercher cette vulnérabilité, le testeur doit identifier toutes les informations de l'utilisateur qui influent sur un ou plusieurs en-têtes de réponse, et vérifier si il/elle peut y injecter une séquence CR + LF. Les en-têtes qui sont les candidats les plus probables pour cette attaque sont les suivantes:

location
set-cookie

Il faut noter qu'une exploitation réussie de cette vulnérabilité dans un scénario réel peut être assez complexe, car plusieurs facteurs doivent être pris en compte:

Le testeur doit correctement définir les en-têtes dans la réponse falsifiée pour qu'elle soit correctement mise en cache (par exemple, un en-tête Last-Modified avec une date fixée dans l'avenir). Il/elle peut également détruire les versions précédemment mises en cache des pages cibles, par l'émission d'une demande préliminaire avec “Pragma: no-cache” dans les en-têtes de requête L'application, sans filtrage de la séquence CR + LF, peut filtrer d'autres caractères qui sont nécessaires pour une attaque réussie (par exemple, “<” et “

>"). Dans ce cas, le testeur peut essayer d'utiliser d'autres codages (par exemple, UTF-7)

C

ertaines cibles (par exemple, ASP) -encodent au format URL la partie du path de l'en-tête location (par exemple, www.victim.com/redirect.asp), ce qui rend inutile une séquence CRLF. Cependant, elles ne parviennent pas à coder la section requête (par exemple,?Interface =advanced), ce qui signifie qu'un point d'interrogation principal est suffisant pour contourner ce filtrage Pour une analyse plus détaillée de cette attaque et d'autres informations sur les scénarios et d'applications possibles, consulter les articles référencés à la fin de cette section.

dwndoc

Table of Contents

Résumé

Description

Test Boîte Noire

HTTP Splitting

Test boîte grise

HTTP splitting

HTTP Smuggling

Références

Livres blancs