Les attaques de type "HTTP response splitting"

Date : 20 Juin 2005

Les attaques de type "HTTP response splitting"

Au mois de mars 2004, une publication a été faite sur Internet pour présenter un nouveau type d'attaque visant les sites web : les attaques par "HTTP response splitting". Depuis, cette attaque s'est popularisée, et nous voyons maintenant de plus en plus souvent, lors de notre veille quotidienne sur les failles de sécurité, des messages du type : "Attention, le produit 'XX' est sensible aux attaques par "HTTP response splitting". Il nous est donc apparu souhaitable de consacrer un article de notre Bulletin mensuel à l'explication de ce type d'attaque.

Pour se limiter à l'essentiel, on pourra noter que les attaques par "HTTP response splitting" ont quelques similitudes qui les rapprochent des attaques par "Cross-site scripting" :

  • Elles ont les mêmes causes. Toutes les deux sont possibles parce que des sites web sont écrits de façon non sûre. En effet une attaque par "HTTP response splitting" n'est possible que si un site web ne contrôle pas suffisamment les paramètres reçus, et les réutilise sans avoir filtré les caractères dangereux qu'ils contiennent.

  • Elles sont toutes les deux des attaques "par injection". Plutôt que d'injecter des données HTML dans le corps d'une page web (cas d'une attaque par "cross-site scripting") le "HTTP response splitting" va cette fois injecter des données dans l'entête des réponses HTTP.

  • Elles peuvent avoir des conséquences similaires. Bien que ce ne soit pas la seule conséquence possible, le "HTTP response splitting" permet par exemple de voler les cookies de session.

Autopsie d'une attaque "HTTP response splitting"

Supposons une application web ayant des pages protégées dont l'accès n'est autorisé que si l'internaute s'est préalablement identifié et authentifié. Dans le cas où un internaute tente d'accéder directement à une page protégée, il est élégant de l'envoyer sur une page d'authentification, puis, une fois l'authentification réussie, de le rediriger automatiquement vers la page qu'il avait demandée.

Cela est le plus souvent réalisé en codant une page d'authentification (par exemple "login.php") acceptant en paramètre une URL vers laquelle l'internaute sera redirigé une fois l'authentification réussie (par exemple avec un paramètre "goto=www.cert-ist.com/avis.php"). L'arrivée sur la page de "login" se fera donc typiquement par une URL du type :

login.php?goto=www.cert-ist.com/avis.php

Une façon "facile" de coder "login.php" consiste, une fois l'authentification réussie, à générer une réponse HTTP de type "refresh: 0" (exemple 1) ou "object moved" (exemple 2). Ces deux exemples ont pour effet de renvoyer l'internaute automatiquement vers la page "http:// www.cert-ist.com/avis.php"

Exemple 1:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 14 Jul 2004 09:48:04 GMT
Content-type: text/html
Refresh: 0; URL=http:// www.cert-ist.com/avis.php
Content-Length: 0

 Exemple 2:

HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.0
Date: Wed, 14 Jul 2004 09:48:04 GMT
Location: http:// www.cert-ist.com/avis.php
Content-Length: 0

 Si l'application est mal écrite, et que la réponse générée reprend in-extenso la valeur du paramètre "goto" fourni par l'utilisateur, alors un attaquant peut insérer dans ce paramètre des retours chariot (code "%0d%0a") et les données qui suivent seront alors interprétées comme des champs de l'entête HTTP.

Par exemple, si :

goto= www.cert-ist.com/avis.php%0d%0aContent-Length:%200%0d%0a%0d
%0aHTTP/1.0%20200%20OK%0d%0aContent-Length:%207%0d%0a%0d%0aGotcha!

Alors la réponse HTTP générée (cas de l'exemple 2) sera alors :

HTTP/1.1 302 Object moved
Connection: close
Date: Sun, 26 Sep 2004 14:14:02 GMT
Server: Microsoft-IIS/6.0
Location: http:// www.cert-ist.com/avis.php
Content-Length:0

HTTP/1.0 200 OK
Content-Length: 7

Gotcha!
Content-Length: 0

On voit ici que la réponse générée prend alors la forme de 2 réponses HTTP collées l'une derrière l'autre. La première réponse est une redirection vers un autre site (réponse "302 Object moved"), et la seconde est une réponse ordinaire (réponse "200 OK"), qui a été injectée dans le flux HTTP, et qui provoquera (si elle est interprétée) l'affichage du texte "Gotcha!" dans le navigateur web qui la recevra.

Une attaque "HTTP response splitting" consiste donc à éclater en deux la réponse HTTP générée par un serveur Web mal écrit en insérant des champs HTTP (et des retours chariots) dans les paramètres envoyés au serveur web.

Quels types d'attaques peut-on réaliser par ce moyen ?

Tout d'abord, ce type d'attaque ne fonctionne que si la deuxième réponse HTTP est interprétée. Dans un cas "ordinaire" (protocole HTTP 1.0) ce ne sera pas le cas car 2 réponses HTTP successives se trouvent normalement dans deux paquets TCP distincts. Dans la réalité cependant, ce sera souvent le cas (en particulier avec HTTP 1.1) car, pour augmenter les performances, les navigateurs et les relais web cherchent de plus en plus à réutiliser la même connexion TCP pour plusieurs requêtes HTTP successives.

Dans ce cas, la seconde réponse HTTP sera interprétée comme la réponse à la requête suivante reçue par le serveur web (requête qui n'est pas forcement encore arrivée !).

La publication de mars 2004 présente de nombreux cas d'attaques théoriques. Nous ne retiendrons ici que celles qui paraissent les plus plausibles :

·         La corruption de cache web. Si l'attaquant envoie deux requêtes successives (une requête "splitting", puis une requête "ordinaire"), alors la réponse injectée par l'attaquant au moyen de la requête "splitting" sera interprétée par le cache web comme étant la réponse à la seconde requête (la requête "ordinaire"). Si cette réponse est mise en cache, alors cette réponse injectée sera renvoyée par le cache à toutes les personnes demandant à consulter la page "ordinaire" choisie par l'attaquant. On peut donc théoriquement réaliser de cette façon un "défacement" de site web.

·         Le vol de données utilisateurs. Dans la mesure où l'attaquant a introduit une réponse supplémentaire dans le flux HTTP, il se produit un décalage entre les requêtes de l'internaute et les réponses renvoyées par le serveur web. Un attaquant peut donc ainsi récupérer la réponse destinée à un autre utilisateur et obtenir des données confidentielles (par exemple les cookies de session) destinées à cet utilisateur.

Pour plus d'information

Article de référence présentant le "HTTP response splitting" : http://www.sanctuminc.com/pdf/WhitePaper_HTTPResponse.pdf

 Exemple de produits vulnérables :

Méthode de test pour détecter les applications vulnérables : http://www.securiteam.com/securitynews/6P00H20BGE.html

 

Précedent Précedent Suivant Suivant Imprimer Imprimer

© 2024 Cert-IST