Le protocole HTTP est décrit dans la RFC (Request For Comments) 2616 que voici : http://repository.root-me.org/RFC/EN%20-%20rfc2616.txt
Ce document détaille entièrement le protocole HTTP. Par exemple, voici les en-têtes que nous avons envoyé pour faire apparaître cette page :
GET /fr/Documentation/Web/HTTP-en-tetes?lang=fr HTTP/1.1
Host: www.root-me.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070508 Iceweasel/2.0.0.4 (Debian-2.0.0.4-0etch1)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: fr,en-us;q=0.8,en;q=0.6,zh-cn;q=0.4,zh-hk;q=0.2
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.root-me.org/fr/Documentation/Web/Il n’y a pas franchement d’intérêt à expliquer chaque header, en général le nom parle de lui-même. Nous pouvons brièvement citer les plus importants : Host est le nom de domaine du site visité, User-Agent est le navigateur utilisé (souvent accompagné du système d’exploitation), accept définit le type de données que l’utilisateur peut recevoir, referer indique la page d’où l’on vient et cookies transmet les données écrites dans le cookie local s’il y en a. Il est aussi à noter que les données POST (données envoyées par le navigateur vers le serveur Web, comme un formulaire par exemple) sont transmises à la fin des headers si nécessaire (en ayant indiqué dans les headers le type de données envoyées et leur taille). Les headers sont juste finalement des données textes où l’on peut mettre n’importe quoi et n’ont aucun poids sécuritairement parlant, ce que nous nous proposons d’illustrer maintenant
Un petit exemple
Si vous n’avez pas encore consulté notre page sur les Injection SQL, nous vous invitons à découvrir le code source qui y est donné en exemple et qui servira à démontrer nos dires. On remarque dans la page admin.php que le script vérifie au préalable que nous sommes bien passés par auth.php pour arriver à cette page. Puisque les headers ne sont que des données texte, nous pouvons nous-mêmes indiquer le referer et dire, même si celà est faux, que nous venons de la page auth.php. En voici l’exemple :
Note : nc est la commande netcat qui permet de se connecter directement à un serveur et de dialoguer avec lui (ici la connexion se fait sur le serveur poc.bases-hacking.org, au port 80, port HTTP classique)
$ nc localhost 80
GET /admin/admin.php HTTP/1.1
Host: poc.root-me.org
Referer: /admin/auth.php
HTTP/1.1 302 Found
Date: Fri, 03 Aug 2007 23:22:58 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.3-1+b1
X-Powered-By: PHP/5.2.3-1+b1
Location: ./
Content-Length: 388
Content-Type: text/html; charset=UTF-8
<html>
<head>
<div align="center"><h1>Root Me Administration Zone</h1></div>
<title>Faille de type SQL Injection et Referrer Spoofing</title> </head>
<body>
<img src="../images/penguinroot.gif">
<br><br>
Bienvenue sur le panel d'administration de Root Me ! Malheureusement, cette page est encore en construction, mais elle sera bientôt là !
</body>
</html>Comme prévu, le serveur nous renvoit bien la page admin.php, bien que nous ne soyons pas du tout passés par la case authentification. On peut remarquer au passage que le serveur communique de la même façon que nous, en commençant par ses headers, indiquant entre autre les données qu’il envoit et leur taille. D’ailleurs, c’est un premier moyen d’en connaître plus sur l’adversaire : type et version du serveur, version de l’interpréteur PHP, etc. Le premier pas vers la sécurisation d’un serveur Web est d’ailleurs la restriction HTTP (suppression des headers X-Powered-By, Server, interdiction de la méthode, TRACE, etc.).
Au final, un protocole n’est rien d’autre qu’un langage de communication normalisé entre deux instances : un client (ici, nous) et un serveur (ici, Apache sur poc.root-me.org). Chacun peut diriger d’une certaine manière la communication en se servant de ce langage.