HTTP - en-têtes   Version imprimable de cet article Enregistrer au format PDF

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é.


par S3cur3D

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.

Documentations publiées dans cette rubrique Documentations publiées dans cette rubrique