Les en-têtes HTTP
Alors pourquoi consacrer une rubrique aux en-têtes HTTP ? La réponse est simple, non pas que ce soit un outil de la sécurité informatique primordial, mais il est bon de savoir se familiariser avec des protocoles communs tels HTTP. Comme dans tout protocole (ARP, TCP, IP, SMTP, etc...), les en-têtes sont primordiales car elles font partie intégrante du message qui va être transporté. Quand on demande à son navigateur d'afficher un site web, note site web transmet et reçoit plein d'informations qui permettent d'afficher ces jolies pages que vous voyez. Nous comptons donc vous faire découvrire ce qui se passe derrière votre navigateur et vous dissuader à tout jamais d'utiliser les headers comme un quelconque outil de sécurité.
Le protocole HTTP est décrit dans la RFC (Request For Comments) 2616 que voici :
RFC HTTP de www.faqs.org
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 /http-headers.html HTTP/1.1
Host: www.bases-hacking.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.bases-hacking.org/fonctionnement-web.html
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 :
//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.bases-hacking.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>Bases Hacking 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 Bases Hacking ! Malheureusement, cett e 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.bases-hacking.org). Chacun peut diriger d'une certaine manière la communication en se servant de ce langage.
