Comme vous pouvez le constater dans cette exemple, le serveur répond par les informations que le client lui a envoyées. Voyons quelques sites ayant TRACE activé :

• www.passport.com
• www.yahoo.com
• www.disney.com
• www.securityfocus.com
• www.redhat.com
• www.go.com
• www.theregister.co.uk
• www.sun.com
• www.oracle.com
• www.ibm.com
• Et la liste est longue ...

Option httpOnly Cookie
httpOnly est une option qui informe les naviguateurs (seulement IE 6 lors de la création de ce document) de ne pas autoriser les languages de scripts (JavaScript, VBScript, etc.) à accéder à l'objet "document.cookie" (cible courante des attaques XSS). La sytaxe s'un httpOnly Cookie est:

set-cookie: name=value; httpOnly

Avec JavaScript on peut tester la fiabilité de cette protection (testé avec IE6 SP1).

<script type="text/javascript">
<!--
function normalCookie() {
document.cookie = "TheCookieName=CookieValue_httpOnly";
alert(document.cookie);
}

function httpOnlyCookie() {
document.cookie = "TheCookieName=CookieValue_httpOnly; httpOnly";
alert(document.cookie);
}
//-->
</script>


<FORM>
<INPUT TYPE=BUTTON OnClick="normalCookie();"
VALUE='Display Normal Cookie'>
<INPUT TYPE=BUTTON OnClick="httpOnlyCookie();"
VALUE='Display HTTPONLY Cookie'>
</FORM>

Résultat du bouton "Display HTTPONLY Cookie"

En essayant ce code, on constate vite qu'avec le paramètre httpOnly, l'objet document.cookie renvoie une valeur nulle. C'est une amélioration sécuritaire très utile pour de nombreuses applications web.

Analyse
Le premier objectif est d'obtenir l'accès à la valeur du cookie, normalement accessible via document.cookie, alors que httpOnly est activé. L'idée est de trouver où cette valeur est située, ormis bien sûr document.cookie. C'est ici que TRACE nous est utile pour éclaircir le problème. TRACE renverra les informations que l'on envoi dans une requete HTTP, ce qui inclue Cookie et Authentification, puisque ce sont des headers HTTP.

Cependant, ce n'est pas une mince affaire que d'envoyer une requête TRACE à partir d'Internet Explorer, même à l'aide d'un FORM HTML (méthode = POST). En fait, IE n'accepte que les méthodes GET et POST dans un FORM. Pour outrepasser cette limitation, nous devons utiliser des technologies avancées de scripting côté client afin de créer et d'envoyer une requete HTTP forgée au serveur cible. De nombreuses technologies le permettent.

<script
type="text/javascript">
<!--
function sendTrace() {
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
xmlHttp.open("TRACE",
"http://foo.bar",false);
xmlhttp.send();
xmlDoc=xmlHttp.responseText;
alert(xmlDoc);
}
//-->
</script>

<INPUT TYPE=BUTTON Onclick="sendTrace();" VALUE="Send Trace Request">

Résultat de la requête TRACE, contenant entre autres le cookie du client.

Le script ci-dessus, qui utilise le contrôle ActiveX XMLHTTP, envoie une requete TRACE au serveur. Si la méthode est activée, ce dernier nous renvoi notre requête HTTP que l'on receptionne et affiche via JavaScript. Les headers peuvent aussi contenir des informations d'authentification. Cela démontre la capacité d'outrepasser la protection "httpOnly" et de se passer de document.cookie, même a travers une connexion SSL.

Il est important de noter deux choses : premièrement, l'envoi de requête TRACE n'est pas limitée à IE, d'autres naviguateurs tels que Mozilla/Netscape en sont capable. Par exmmple, dans Mozilla, on peut utiliser l'objet XMLDOM. Deuxièmement, XMLHTTP n'est qu'un contrôle parmi d'autres à posseder cette fonction.

Il subsiste cependant un facteur qui limite l'étendue du danger. La connection TRACE effectuée par le browser est limitée au domaine ou se situe notre script. Ainsi, un script hebergé sur http://foo.bar ne pourra effectuer un TRACE que sur le domaine foo.bar. Néanmoins cette restriction peut etre contournée comme nous allons le voir.

Pour amplifier l'étendue de l'exploit, il faut utiliser une vulnérabilité de restriction de domaine dans IE (ou le naviguateur de votre choix). Pour cela, reférezà un forum tel que bugtraq. Récemment (relatif au 1/20/2003), une faille a été découverte dans les restrictions de domaine d'IE. Ce defaut, découvert par GreyMagic Security, étend la severité du problème.