Sbastien Contreras

Avril 2004

Tutorial HTTP

1 1.1 1.2 1.3 2 2.1 2.2 2.3 3 4 4.1 4.2 5 5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.5 6 7 8 8.1 8.1.1 8.1.2 8.2 8.3 8.4 8.5 8.6 9 9.1 9.2 9.3 9.3.1 9.3.2 10 10.1 10.2 11 11.1 11.2 12

Introduction.......................................................................................................................................3 Propos du document ..........................................................................................................................3 Introduction .........................................................................................................................................3 De HTTP 1.0 HTTP 1.1 ...................................................................................................................3 URL HTTP ..........................................................................................................................................4 Format dune URL HTTP....................................................................................................................4 Champs de lURL HTTP .....................................................................................................................4 Encodage dURL ................................................................................................................................4 Mthodes HTTP ................................................................................................................................5 Requte et rponse HTTP................................................................................................................6 Requte HTTP....................................................................................................................................6 Rponse HTTP...................................................................................................................................6 En-ttes HTTP ...................................................................................................................................7 En-ttes gnriques ...........................................................................................................................7 En-ttes de la requte ........................................................................................................................7 En-ttes de la rponse .......................................................................................................................7 En-ttes Hop-by-hop et en-ttes End-to-End.....................................................................................7 Hop-by-hop.........................................................................................................................................8 End-to-end ..........................................................................................................................................8 Considrations scuritaires concernants les en-ttes HTTP .............................................................8 Codes de statuts...............................................................................................................................9 Connexions persistantes...............................................................................................................10 Cache ...............................................................................................................................................11 Deux types de cache ........................................................................................................................11 Cache du browser ............................................................................................................................11 Cache proxy .....................................................................................................................................11 En-ttes en relation avec le mcanisme de cache...........................................................................11 If-Modified-Since : Get conditionnel .................................................................................................11 En-tte Cache-Control......................................................................................................................11 Utilisation de la mthode Head par un proxy ...................................................................................12 Etag ..................................................................................................................................................12 Ngociation de contenu.................................................................................................................13 En-ttes concernant la ngociation de contenu ...............................................................................13 Exemple de ngociation de contenu ................................................................................................13 Interaction entre ngociation de contenu et cache ..........................................................................13 Hypothse.........................................................................................................................................13 Solution.............................................................................................................................................14 Cookies............................................................................................................................................15 Champs dun cookie .........................................................................................................................15 Scurit.............................................................................................................................................16 Authentification ..............................................................................................................................17 Basic .................................................................................................................................................17 Digest................................................................................................................................................17 Redirection ......................................................................................................................................18
Laboratoire de transmission de donnes / EIG 1

Sbastien Contreras

Avril 2004

13

Analyse de protocole .....................................................................................................................18

14 Encodage base 64 ..........................................................................................................................19 14.1.1 Quand lencodage base 64 est-il utilis ? ....................................................................................19 14.1.2 Principe ........................................................................................................................................19 14.1.3 Exemple : Conversion de eig .................................................................................................19 14.1.4 Failles lies lencodage en base 64 : ........................................................................................19 15 16 Conclusion ......................................................................................................................................21 Sources............................................................................................................................................21

Laboratoire de transmission de donnes / EIG

Sbastien Contreras

Avril 2004

1 1.1

Introduction Propos du document Ce document a pour but de fournir les notions de base du protocole HTTP et de sensibiliser les lecteurs aux failles de scurit inhrentes ce protocole. Ce document est bas en partie sur les travaux de diplme de M. Tissot (EIVD 2003) et de M. Zanetta (EIG 2002). Une acquisition Ethereal dtaille destine illustrer diffrents points de ce document se trouve au paragraphe 13. Introduction HTTP (Hypertext Transfer Protocol) permet daccder aux fichiers situs sur le rseau Internet. Il est notamment utilis pour le World Wide Web. En matire de protocole, HTTP se place au dessus de TCP et fonctionne selon un principe de requte/rponse : le client transmet une requte comportant des informations sur le document demand et le serveur renvoie le document si disponible ou, le cas chant, un message derreur.
Requte: Get fichier index.html

1.2

Reponse: Ok Client
index.html

Serveur

HTTP est un protocole sans connexion et chaque couple requte/rponse est de ce fait indpendant. 1.3 De HTTP 1.0 HTTP 1.1 Ce protocole a t cr au CERN au dbut des annes 1990 afin de fournir au Web un protocole de transfert simple. Deux versions du protocole existent : HTTP 1.0 dfinit en 1996 par la RFC 1945 HTTP 1.1 dfinit en 1999 par la RFC 2616 La version 1.1 apporte, entre autre, les amliorations suivantes : Cinq nouvelles mthodes ( 3) Connexions persistantes ( 7) Digest Authentication ( 11.2)

Laboratoire de transmission de donnes / EIG

Sbastien Contreras

Avril 2004

URL HTTP Un URI (Uniform Resource Identifier) est une chane de caractres structure permettant didentifier de manire unique une ressource dans un espace de nom donn. Cette ressource peut tre dsigne soit par un URN (Uniform Resource Name) soit par un URL (Uniform Resource Locator). URN et URL sont des sous-ensembles de URI. Un URN permet didentifier une ressource par son nom mme lorsque celle ci nest plus disponible. Un URL permet de localiser une ressource. Dans le cas du protocole HTTP, une URL permet de localiser une page HTML, un fichier texte, un script cgi, une image...

2.1

Format dune URL HTTP Le format gnral dune URL HTTP est le suivant :
HTTP://<host>:<port>/<path>?<query>#<fragment>

2.2

Champs de lURL HTTP Champ host Description Permet de spcifier le FQDN (ou adresse IP) du serveur possdant la ressource accder

port

Permet de spcifier le numro de port utiliser pour atteindre le serveur possdant la ressource. Si sa valeur est 80 (port par dfaut du protocole HTTP), il nest pas ncessaire de spcifier le numro de port dans lURL.

path

Permet de spcifier lemplacement du fichier sur le serveur. Ce champ est en gnral constitu dune suite de rpertoires spars par des / puis du nom du fichier accder.

query

Permet de passer un, ou plusieurs, paramtre(s) un script PHP, Perl etc.

fragment

Permet dindiquer une position (ancre, fragment) dans une page

2.3

Encodage dURL Les caractres ne pouvant tre reprsents dans une URL ( ; / ? & ) doivent tre escaped. Afin de rendre escaped un caractre (par exemple &), il faut remplacer ce caractre par son code ASCII cod en hexadcimal (26 pour & ) et le faire prcder par le caractre %. Le caractre & devient donc %26 et un espace devient donc %20. Exemples : http://www.exemple.com http://www.exemple.com:80/News/Search?var1=janvier http://www.exemple.com/Texte%20Avec%20Espace/Exemple.html Pour plus dinformations concernant les rgles dencodage dURL, se rfrer au document [5].

Laboratoire de transmission de donnes / EIG

Sbastien Contreras

Avril 2004

Mthodes HTTP Les mthodes HTTP les plus frquemment utilises sont : GET, POST et HEAD Cinq autres mthodes sont cependant dfinies par la version 1.1 du protocole. Le tableau suivant dtaille les mthodes HTTP disponible en fonction de la version du protocole. Mthodes Get Post Head Options Put Delete Trace Connect 1.0 1.1 Description Permet de demander un document Permet de transmettre des donnes (dun formulaire par exemple) lURL spcifie dans la requte. LURL dsigne en gnral un script Perl, PHP Permet de ne recevoir que les lignes den-tte de la rponse, sans le corps du document Permet au client de connatre les options du serveur utilisables pour obtenir une ressource Permet de transmettre au serveur un document enregistrer lURL spcife dans la requte Permet deffacer la ressource spcifie Permet de signaler au serveur quil doit renvoyer la requte telle quil la reue Permet de se connecter un proxy ayant la possibilit deffectuer du tunneling

Certaines de ces mthodes ncessitent , en gnral, une authentification du client. Pour plus dinformations concernant les mthodes HTTP, se rfrer aux paragraphes 5.1.1 et 9 du document [2].

Laboratoire de transmission de donnes / EIG

Sbastien Contreras

Avril 2004

4 4.1

Requte et rponse HTTP Requte HTTP La requte transmise par le client au serveur comprend : 1. une ligne de requte (request-line) contenant la mthode utilise, lURL du service demand, la version utilise de HTTP 2. une ou plusieurs lignes d'en-ttes, chacune comportant un nom et une valeur. La requte peut optionnellement contenir une entit (contenu). Celle-ci est notamment utilise pour transmettre des paramtres avec la mthode POST. L'entit est transmise aprs les lignes d'en-ttes, elle est spare de la dernire en-tte par un double CRLF (carriage return et linefeed).
GET /index.html HTTP/1.1 Host: www.example.com Accept: */* Accept-Language: fr User-Agent: Mozilla/4.0 (MSIE 6.0; windows NT 5.1) Connection: Keep-Alive

Dans cet exemple, le client demande le document l'adresse http://www.example.com/index.html, il accepte tous les types de document en retour, prfre les documents en franais, utilise un navigateur (browser) compatible Mozilla 4.0 sur un systme Windows NT 5.1 (Windows XP) et signale au serveur qu'il faut garder la connexion TCP ouverte l'issue de la requte (car il a d'autres requtes transmettre). Pour plus dinformations concernant les requtes HTTP, se rfrer au paragraphe 5 de [2]. 4.2 Rponse HTTP La rponse transmise par le serveur au client comprend : 1. une ligne de statut (status-line) contenant la version de HTTP utilise et un code dtat 2. une ou plusieurs lignes den-ttes, chacune comportant un nom et une valeur 3. Le corps du document retourn (les donnes HTML ou binaires par exemple). Une rponse ne contient pas obligatoirement un corps (exemple : sil sagit dune rponse une requte HEAD, seule la ligne de statut et les en-ttes sont retourns. La dernire ligne d'en-tte est suivie d'un double CRLF marquant le dbut du corps du document retourn (les donnes HTML ou binaires par exemple).
HTTP/1.1 200 OK Date: Mon, 15 Dec 2003 23:48:34 GMT Server: Apache/1.3.27 (Darwin) PHP/4.3.2 mod_perl/1.26 DAV/1.0.3 Cache-Control: max-age=60 Expires: Mon, 15 Dec 2003 23:49:34 GMT Last-Modified: Fri, 04 May 2001 00:00:38 GMT ETag: "26206-5b0-3af1f126" Accept-Ranges: bytes Content-Length: 1456 Content-Type: text/html <!DOCTYPE html PUBLIC "-//W3C//DTD Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1transitional.dtd"> <html> ... XHTML 1.0

Dans cet exemple, le code 200 nous indique que le document demand a t trouv. Pour faciliter la gestion du cache du client, le serveur transmet la date actuelle, la date de dernire modification du document et la date d'expiration (aprs laquelle le document doit tre demand nouveau). L'en-tte Content-Type nous apprend que le document retourn est de type HTML et l'en-tte ContentLength indique que le corps du document a une longueur de 1456 octets. L'en-tte Server renseigne sur le logiciel serveur utilis. Lenvoi dune telle information nest pas recommand dun point de vue scuritaire. Pour plus dinformations concernant les requtes HTTP, se rfrer au paragraphe 6 de [2].

Laboratoire de transmission de donnes / EIG

Sbastien Contreras

Avril 2004

5 5.1

En-ttes HTTP En-ttes gnriques Certains en-ttes peuvent se trouver aussi bien dans la requte que dans la rponse. Les principaux sont donns dans le tableau ci-dessous : Champ Content-length Description Longueur en octets des donnes suivant les en-ttes

Content-type

Type MIME des donnes qui suivent

Connection

Indique si la connexion TCP doit rester ouverte (Keep-Alive) ou tre ferme (close)

5.2

En-ttes de la requte Les en-ttes suivants nexistent que dans les requtes HTTP. Seul len-tte Host est cependant obligatoire dans la version 1.1 de HTTP. La version 1.0 de HTTP ne possde pas den-ttes obligatoires. Champ Accept Accept-encoding Accept-language Cookie Host If-modified-since If-none-match Referer User-agent Description Types MIME que le client accepte Mthodes de compression supportes par le client Langues prfres par le client (pondres) Donnes de cookie mmorises par le client Hte virtuel demand Ne retourne le document que si modifi depuis la date indique Ne retourne le document que sil a chang URL de la page partir de laquelle le document est demand Nom et version du logiciel client

Pour plus dinformations concernant les en-ttes des requtes HTTP, se rfrer au paragraphe 5.3 de [2]. 5.3 En-ttes de la rponse Champ Allowed Content-encoding Content-language Date Expires Last-modified Location Etag Pragma Server Set-cookie Description Mthodes HTTP autorises pour cette URI (comme POST) Mthode de compression des donnes qui suivent Langue dans laquelle le document retourn est crit Date et heure UTC courante Date laquelle le document expire Date de dernire modification du document Adresse du document lors dune redirection Numro de version du document Donnes annexes pour le navigateur (par exemple, no.cache) Nom et version du logiciel serveur Permet au serveur dcrire un cookie sur le disque du client

Pour plus dinformations concernant les en-ttes des rponses HTTP, se rfrer au paragraphe 6.2 de la RFC 2616 [2]. 5.4 En-ttes Hop-by-hop et en-ttes End-to-End Les en-ttes dtaills dans le 5 peuvent tre de deux types : Hop-by-hop ou End-to-end.

Laboratoire de transmission de donnes / EIG

Sbastien Contreras

Avril 2004

5.4.1

Hop-by-hop Ces en-ttes sont destins tre examins par tout nud recevant le paquet. Les en-ttes suivants sont de type Hop-by-hop : Connection Proxy-authenticate Proxy-authorization TE Trailers Transfer-Encoding Upgrade

5.4.1.1 Exemple Prenons le cas dun client devant passer par un proxy afin de pouvoir envoyer des requtes HTTP sur Internet. Le proxy ncessite une authentification du client et va pour se faire utiliser len-tte Proxy-authenticate. 1. => 2. => 3. => 4. => Le client va donc tablir une connexion TCP entre lui et le proxy puis il va envoyer au proxy sa requte HTTP. Le client ntant pas encore authentifi, le proxy va lui retourner une rponse possdant len-tte proxy-authenticate. Le client ritre sa requte en y ajoutant les donnes dauthentification demandes par le serveur. Les donnes dauthentification sont places dans len-tte proxy-authorization. Une fois le client correctement authentifi, le proxy tablit alors une connexion TCP avec le serveur demand puis lui transmet la requte mise par le client. Len-tte proxyauthorization nest pas transmise par le proxy.
1/ Get / HTTP/1.1 host: www.google.fr 2/ HTTP/1.1 407 Proxy authentication required proxy-authenticate: Basic realm=Web Client 3/ Get / HTTP/1.1 proxy-authorization: Basic xxx 4/ Get / HTTP/1.1 host: www.google.fr Router Serveur

Il apparat clairement que les en-ttes proxy-authenticate et proxy-authorization nont de sens que pour la communication entre le client et le proxy. Ces en-ttes ne doivent pas tre transmis. 5.4.2 End-to-end Ces en-ttes sont destins au destinataire final de la requte (ou de la rponse) HTTP. De ce fait, ces enttes doivent tre ignors par les nuds (proxies, routeurs) constituant le chemin suivi par le paquet. Les nuds vont donc simplement transmettre ces en-ttes au destinataire final. Tous les en-ttes sont de type end-to-end excepts ceux prsents dans le paragraphe 5.4.1. 5.5 Considrations scuritaires concernants les en-ttes HTTP Les en-ttes permettent de fournir aux deux protagonistes dun change HTTP des informations afin doptimiser (cache, connection keep-alive) et de personnaliser (ngociation de contenu, cookies) le contenu chang. Cependant, certaines informations transmises dans ces en-ttes ne devraient pas tre divulgue pour des raisons de scurit. Cest le cas de len-tte Server. En effet, la premire action entreprise par un hacker lors dune tentative dintrusion dun systme consiste identifier le systme en question. Cette identification peut tre effectue par prise dempreinte du systme grce un outil du type NMAP (ou P0f pour une prise dempreinte passive) ou, plus simplement, en regardant la valeur de len-tte Server reue aprs avoir effectu une requte HTTP. Par dfaut, un serveur Web IIS 6 aura pour en-tte Server :
Server: Microsoft-IIS/6.0

Solution : Len-tte Server (tout comme dautres en-ttes) peut tre modifi laide dun proxy applicatif (Blue Coat par exemple, cf. [8] 4.3.4) afin dafficher une information fausse ou de laisser len-tte Server vide.
Laboratoire de transmission de donnes / EIG 8

Sbastien Contreras

Avril 2004

Codes de statut Lorsque le serveur renvoie un document, il lui associe un code de statut renseignant ainsi le client sur le rsultat de la requte (requte invalide, document non trouv). Les principales valeurs des codes de statut HTTP sont dtailles dans le tableau ci-aprs. Cod Nom e Information 1xx 100 Continue 101 Switching protocol Succs 2xx 200 OK 201 Created 202 Accepted 204 No response 206 Partial content Redirection 3xx 301 Moved 302 Found 304 Not modified Erreurs du client 4xx 400 Bad request 401 Unauthorized 403 Forbidden 404 Not found 405 Method not allowed Erreurs du serveur 5xx 500 Internal error 501 Not implemented 502 Bad gateway Description Utiliser dans le cas o la requte possde un corps. Rponse une requte Le document a t trouv et son contenu suit Le document a t cr en rponse un PUT Requte accepte, mais traitement non termin Le serveur na aucune information renvoyer Une partie du document suit Le document a chang dadresse de faon permanente Le document a chang dadresse temporairement Le document demand na pas t modifi La syntaxe de la requte est incorrecte Le client na pas les privilges daccs au document Laccs au document est interdit Le document demand na pu tre trouv La mthode de la requte nest pas autorise Une erreur inattendue est survenue au niveau du serveur La mthode utilise nest pas implmente Erreur de serveur distant lors dune requte proxy

Pour plus dinformations concernant les codes de statut, se rfrer aux paragraphes 6.1.1 et 10 de la RFC 2616.

Laboratoire de transmission de donnes / EIG

Sbastien Contreras

Avril 2004

Connexions persistantes La fonctionnalit de connexions persistantes apparue avec la version 1.1 du protocole HTTP est sans doute lamlioration la plus notable par rapport la version 1.0. Avec la version 1.0 de HTTP, une nouvelle connexion TCP doit tre tablie pour chaque URL demande. Avec la version 1.1, une connexion TCP existante peut tre rutilise pour demander dautres URLs. De plus, il est possible avec la version 1.1 dHTTP deffectuer sur une seule connexion TCP plusieurs requtes HTTP sans avoir attendre les rponses HTTP (Pipelining).
HTTP 1.0
tablissement TCP

HTTP 1.1
tablissement TCP

Get /image1.jpg HTTP/1.1 Ok Data image1.jpg libration TCP

Get /image1.jpg HTTP/1.1 Ok Data image1.jpg Get /image2.jpg HTTP/1.1 Ok Data image2.jpg libration TCP

Client

Serveur

Client

Serveur

tablissement TCP

Get /image2.jpg HTTP/1.1 Ok Data image2.jpg Etablissements et librations TCP libration TCP Requtes et rponses HTTP

Cette amlioration permet de : diminuer la charge CPU (pour les routeurs, serveurs Web, clients, proxies) engendre par les tablissements TCP diminuer le nombre de paquets transitant sur le rseau d aux tablissements TCP diminuer la latence engendre par ltablissement de connexion TCP Les clients dsirant maintenir une connexion TCP ouverte doivent inclure dans leur requte HTTP len-tte Connection: keep-alive Pour plus dinformations concernant les connexions persistantes, se rfrer au paragraphe 8.1 de la RFC 2616.

Laboratoire de transmission de donnes / EIG 10

Sbastien Contreras

Avril 2004

Cache Une page HTML est souvent constitue dinformations (textes ou images) ne subissant aucune modification pendant plusieurs jours. Il devient alors intressant de mettre en cache les objets pour lesquels nous avons dj effectu une requte.

8.1 8.1.1

Deux types de cache Cache du navigateur Les browsers actuels possdent, normalement, tous la fonctionnalit de cache. Ce cache va permettre au browser de fournir immdiatement les objets prsents dans le cache sans avoir effectuer une requte auprs du serveur possdant lobjet.. Dans le cas dInternet Explorer 6, les rglages conernant le cache de ce navigateur sont disponibles de la manire suivante : Start > Settings > Control panel > Internet options Dans longlet General, cliquer sur Settings Cache proxy Les proxies HTTP possdent souvent, entre autre, la fonctionnalit de cache. Ce cache va permettre au proxy de fournir aux clients les objets prsents dans son cache sans quil doive effectuer une requte HTTP auprs du serveur possdant lobjet. Ce cache est la disposition de tous les clients utilisant le proxy. En-ttes en relation avec le mcanisme de cache Rponse HTTP :
HTTP/1.1 200 Ok Content-Type: image/gif Server: GWS/2.1 Content-length: 8866 Last-Modified: Tue, 23 Sep 2003 03:21:11 GMT Expires: Sun, 17 Jan 2038 19:14:07 GMT Date: Wed, 14 Apr 2004 13:20:30 GMT Data..

8.1.2

8.2

Comme nous pouvons le constater, la rponse HTTP contenant lobjet demand est accompagne de plusieurs en-ttes dont certains permettent dagir sur le fonctionnement du cache. Ces en-ttes sont (liste non exhaustive) : Last-Modified If-Modified-Since Date Expires Cache-Control ETag Les 4 premiers en-ttes taient dj prsents dans la version 1.0 de HTTP. Les en-ttes Cache-Control et ETag sont des nouveauts de la version 1.1 du protocole. 8.3 If-Modified-Since : Get conditionnel Un Get conditionnel peut tre effectu en incluant len-tte If-Modified-Since dans une requte Get HTTP. Cet en-tte permet de spcifier au serveur HTTP que lon ne dsire recevoir le fichier demand que sil a subit des modifications depuis la date indique dans len-tte.
Get news.htm If-Modified-Since: Thu, 1 Apr 2004 08:05:31 GMT

Client HTTP/1.1 304 Not Modified

Serveur
news.htm Last Modification= Tue, 30 Mar 15:30:00 GMT

8.4

En-tte Cache-Control Cet en-tte permet un contrle accru des mcanismes de cache et offre une gestion plus efficace du cache. Plusieurs directives peuvent tre places dans un en-tte Cache-Control.
Laboratoire de transmission de donnes / EIG 11

Sbastien Contreras

Avril 2004

Exemples de directives :
Directive max-age private public Description Spcifie le temps (en secondes) maximum durant lequel lobjet peut tre considr comme frais Indique que la rponse ne doit pas tre mise en cache Indique que la rponse peut tre mise en cache par nimporte quel cache

La liste exhaustive des directives existantes pour len-tte Cache-Control est disponible au paragraphe 14.9 du document [2]. 8.5 Utilisation de la mthode Head par un proxy Comme vu au paragraphe 3 de ce document, la mthode Head permet de ne rcuprer que les lignes den-ttes dune rponse un Get. Cette mthode permet des gains de performance non ngligeable dans certains cas. Exemple : Un proxy utilis par les employs de la socit X possde la fonction de cache HTTP. Les fichiers les plus frquemment consults sont donc prsents dans son cache et peuvent tre retourns directement aux employs lorsquils sont demands. Afin de ne pas fournir des documents prims , le proxy doit rgulirement vrifier si une nouvelle version du fichier stock en cache nest pas disponible. Pour ce faire, le proxy peut effectuer une requte Head sur le fichier en question afin dobtenir la date de dernire modification du fichier (en-tte Last-Modified). Si cette date est plus rcente que la date du fichier prsent en cache, alors le proxy va effectuer une requte Get sur le fichier afin de possder la dernire version du fichier. Sinon la version du fichier prsente en cache est considre comme frache et donc conserve. Lutilisation de la mthode Head permet ainsi dviter la transmission du fichier lorsque celle ci est inutile. 8.6 Etag Un ETag est une valeur gnre par le serveur Web permettant didentifier de manire unique un objet. Exemple : ETag: 606ea2cbbefc31:872

Un ETag est cr lorsquun nouvel objet est mis disposition sur le serveur Web. Cet ETag est modifi chaque modification de lobjet en question. Un Etag est souvent utilis avec les en-ttes If-Match et If-None-Match.
Get image.gif If-None-Match: '606ea2cbbefc31:872'

Client HTTP/1.1 304 Not Modified

Serveur

image.gif If-None-Match:'606ea2cbbefc31:872'

Pour plus dinformations concernant le mcanisme de cache HTTP, se rfrer au document [5].

Laboratoire de transmission de donnes / EIG 12

Sbastien Contreras

Avril 2004

Ngociation de contenu La ngociation de contenu a pour but de fournir un client la reprsentation la mieux adapte ses besoins. Exemple : Un site portail international propose des informations en plusieurs langues. Lutilisateur arrive sur le site sur une page index.html o il doit slectionner la langue dans laquelle il veut consulter les informations. Il serait intressant de pouvoir automatiser cette phase et donc, de fournir lutilisateur la reprsentation approprie des informations, sans quil ne doive slectionner la langue dsire. La version 1.1 de HTTP permet cette automatisation grce len-tte Accept-Language. Cet en-tte est, normalement, prsent dans toute requte HTTP. Cet en-tte accepte plusieurs valeurs simultanment. Exemple : Accept-Language: fr, en Il est galement possible de pondrer ses prfrences. Exemple : Accept-Language: fr ; q=1.0 , en ; q=0.8 Ces principes sont applicables aux jeux de caractres, types de fichiers textuel (HTML ou .txt), types dimages (JPEG ou GIF) Plus dinformations concernant la ngociation de contenu est disponible au paragraphe 12 de [2]. Des informations concernant la ngociation de contenu et lalgorithme de ngociation de contenu utilis par Apache sont disponibles dans le document [6].

9.1

En-ttes concernant la ngociation de contenu

En-tte Accept Accept-Language Accept-Charset Accept-Encoding Description Permet de spcifier les prfrences concernant les types audio, textuels, images Permet de spcifier les prfrences concernant les langues Permet de spcifier les prfrences concernant les jeux de caractres Permet de spcifier les prfrences concernant les compressions et encodages

Pour plus dinformations concernant ces en-ttes, voir les paragraphes 14.1, 14.2, 14.3 et 14.4 du document [2].

9.2

Exemple de ngociation de contenu 1. Le client effectue une requte afin dobetnir le fichier news.html. Il spcifie galement que le fichier voulu doit lui tre retourn en franais en priorit. 2. Le serveur possde deux versions du fichier : - version franaise - version anglaise Ayant connaissance des prfrences du client grce len-tte Accept-Language reu, le serveur va retourner la version franaise du document.
1/ Get news.html HTTP/1.1 Accept-Language: fr

Client 2/ HTTP/1.1 200 Ok

version francaise

Serveur
version anglaise version francaise

news.html news.html news.html

9.3 9.3.1

Interaction entre ngociation de contenu et cache Hypothse Les employs de la socit X passent par un proxy HTTP, pourvu de la fonctionnalit de cache, pour surfer sur le Web. Un utilisateur A effectue une requte pour obtenir le fichier news.html, en version anglaise, du serveur Y.
Laboratoire de transmission de donnes / EIG 13

Sbastien Contreras

Avril 2004

Ce fichier est plac en cache par le proxy. Un utilisateur B effectue une requte pour obtenir le mme fichier news.html, en version franaise, du serveur Y. Le proxy va retourner immdiatement le fichier en cache sans envoyer de nouvel requte au serveur Y. Lutilisateur B ne pourra donc pas obtenir le fichier dans la langue dsire. 9.3.2 Solution Il faut donc utiliser, par exemple, len-tte Cache-Control: private afin dempcher la mise en cache des documents obtenus laide dun mcanisme de ngociation de cache. Par dfaut, un serveur Apache empche la mise en cache de tels documents.

Laboratoire de transmission de donnes / EIG 14

Sbastien Contreras

Avril 2004

10

Cookies Comme prcis dans le paragraphe 1.2, le protocole HTTP ne possde pas de mcanisme de session. Pour pallier ce manque, Netscape a cr les cookies afin de fournir HTTP un mcanisme de gestion dtats. Les cookies vont permettre au serveur de mmoriser des donnes du ct client. Cela permet un suivi de lutilisateur dune requte lautre et dimplmenter ainsi la notion de session. Afin de donner lordre au client de crer un cookie, le serveur place un en-tte Set-Cookie dans sa rponse comprenant : le nom du cookie sa valeur son contexte (path) sa date dexpiration Le schma de squence suivant symbolise un client qui, aprs avoir rempli un formulaire (username/password) : 1. Envoi (Post) les donnes un script login.cgi 2. Le serveur informe le client que les donnes ont t correctement reues par le script (200 Ok) et demande au client de crer un cookie ayant pour valeur SESSID=aoih4m et expirant le 06.06.2003 18:06:56. 3. Le client effectue une requte pour obtenir le fichier index.html en joignant la requte le cookie cr en 2. 4. Aprs avoir vrifi que la valeur SESSID correspondait bien une session valide, le serveur renvoie le fichier demand au client
1/ Post /login.cgi HTTP/1.1 2/ HTTP/1.1 200 Ok Set-Cookie: SESSID=aoih4m; expires=06.06.2006 18:06:56 Client 3/ Get /index.html HTTP/1.1 Cookie: SESSID=aoih4m 4/ HTTP/1.1 200 OK Serveur

Un cookie est souvent utilis afin de mmoriser : une cl de session validit limite les prfrences de lutilisateur concernant un site Web les achats raliss par lutilisateur etc 10.1 Champs dun cookie NAME : Value :

Obligatoire, NAME est le nom attribu par le serveur au cookie. Obligatoire, VALUE est une valeur attribue au cookie par le serveur et est thoriquement dnue de sens pour l'utilisateur. Cette valeur sert identifier l'utilisateur au serveur. Optionnel, comme les cookies peuvent tre utiliss pour enregistrer des informations sensibles sur un utilisateur, ce champ est utilis par le serveur pour dcrire comment il va utiliser ce cookie. L'utilisateur peut inspecter ce champ pour dcider s'il veut continuer les changes avec le serveur ou pas.

Comment=value:

CommentURL=URL : Optionnel, idem que prcdemment sauf que dans ce cas, les informations concernant lutilisation du cookie faite par le serveur sont disponibles lurl URL Discard : Optionnel, sert informer le navigateur qu'il peut ignorer le cookie ds que l'utilisateur termine sa session. Dcrit comme optionnel par la RFC 2965 mais en ralit obligatoire, sert spcifier le domaine pour lequel le cookie est valide. Il est utilis par le navigateur pour savoir qui (serveur) le cookie doit tre envoy.

Domain= value :

Laboratoire de transmission de donnes / EIG 15

Sbastien Contreras

Avril 2004

Max-Age= value : Optionnel, donne l'age maximum du cookie avant qu'il ne soit "prim". Sa valeur est en seconde, depuis le 1er janvier 1970 00:00:00 GMT. Lorsque ce champ n'est pas spcifi, le navigateur mmorise le cookie et le dtruit lorsque l'utilisateur ferme le navigateur. Un tel cookie est dit de session alors quun cookie possdant une valeur dfinie de Max-Age est dit persistant. Path= value : Optionnel, spcifie le chemin sur le serveur auquel le cookie s'applique.

Port= portlist : Optionnel, sert restreindre un cookie un ou plusieurs port(s) spcifique(s). Secure : Optionnel, c'est un boolen qui spcifie si une connexion SSL est ncessaire pour accder au cookie.

Version= value : Obligatoire, ce champ identifie la version du mcanisme de gestion d'tat. Pour plus dinformations concernant les cookies, voir le document [4] Sur un systme XP, il est possible de visualiser les cookies partir de C:\Documents and Settings\user\Cookies et de les supprimer (Start > Control Panel > Internet Options > Delete Cookies...). 10.2 Scurit Les cookies ne prsentent pas un danger en eux mmes. Ils peuvent cependant gnrer des failles dans le cas o, par exemple, ils sont utiliss pour authentifier un utilisateur X en contenant le numro de session. Dans un tel cas, une personne Y mal intentionne pourrait voler le cookie et se connecter au site en tant authentifi en tant que X. Les cookies sont galement souvent utiliss dans les attaques de type Cross-Site Scripting (cf. http://www.cgisecurity.com/articles/xss-faq.shtml pour plus dinformations sur le Cross-Site Scripting).

Laboratoire de transmission de donnes / EIG 16

Sbastien Contreras

Avril 2004

11

Authentification Laccs certains documents peut ncessiter une authentification du client. Dans la version 1.0 du protocole HTTP, seule lauthentification de type Basic tait disponible. La version 1.1 ajoute lauthentification de type Digest.

11.1

Basic 1. => GET http://www.google.ch HTTP/1.1 Pour consulter une page Web, le navigateur envoie une requte HTTP au serveur contenant lURL du document obtenir. 2. <= HTTP/1.1 401 Unauthorized WWW-Authenticate: BASIC realm=private Le serveur va retourner au navigateur une rponse HTTP possdant un code de statut 401 (Unauthorized) avec len-tte www-authenticate. Cet en-tte est suivie par le nom de la mthode dauthentification utiliser (Basic) et le royaume (realm) auprs du quel lauthentification doit tre faite. Le schma dautorisation est gnralement le schma BASIC. BASIC = Encodage_Base_64(username:password) (cf. 14 pour plus dinformations concernant lencodage au format base 64) Len-tte www-authenticate indique galement auprs de quel domaine (realm) lutilisateur doit sauthentifier. 3. => GET http://www.google.ch HTTP/1.1 Authorization: BASIC xxx Le client ritre sa requte en y ajoutant son username:password (spars par : ) encod au format BASIC, comme demand par len-tte WWW-Authenticate. BASIC = Encodage_Base_64(username:password) 4. <= HTTP/1.1 200 OK Data.. Une fois le client correctement authentifi par le serveur, ce dernier enverra au client les ressources demandes.
1/ Get http://www.google.ch 2/ HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm=private 3/ Get http://www.google.ch Authorization: Basic xxx 4/ HTTP/1.1 200 OK Data...

Client

Serveur

11.2

Digest Lauthentification de type Digest est base sur lauthentification de type Basic et sur un mcanisme de Challenge/Response. Le Challenge/Response permet dviter la transmission du mot de passe sur le rseau (cest un hash MD5 du mot de passe et du challenge qui est transmis la place) ainsi que les replay attacks (grce la valeur alatoire quest le challenge).

Pour plus dinformations concernant lauthentification HTTP de type Digest, se rfrer au paragraphe 3 du document [3].

Laboratoire de transmission de donnes / EIG 17

Sbastien Contreras

Avril 2004

12

Redirection Lorsque le serveur renvoie un code de statut de la srie 3xx, il accompagne sa rponse dun en-tte Location indiquant la nouvelle adresse du document. Dans ce cas, le navigateur va automatiquement mettre une requte vers cette nouvelle adresse.
1/ GET /old.html HTTP/1.1 Host: exemple.com 2/ HTTP/1.1 301 Moved Location: http://exemple.com/new.html 3/ Get /new.html HTTP/1.1 Host: exemple.com 4/ HTTP/1.1 200 OK Data...

Client

Serveur

13

Analyse de protocole Lacquisition a t effectue laide dEthereal (www.ethereal.com).

Scnario : Un client effectue une requte sur le serveur www.google.fr

Etablissement TCP entre le client et le serveur

GET / HTTP/1.1 host: www.google.fr Connection Keep-Alive Client HTTP/1.1 200 Ok Connection Keep-Alive Set-cookie: PREF=ID=... Data

Requte HTTP Get Spcifie quel hte est destine la requte Le client dsir maintenir la connexion Serveur Le document a t trouv et suit les enttes Le serveur dsire maintenir la connexion Demande de cration d'un cookie Dbut de l'envoie des donnes

Data

Le serveur envoie la suite du fichier dans des paquets HTTP dpourvues d'enttres

GET /intl/fr_fr/images/logo.gif HTTP/1.1 host: www.google.fr Connection Keep-Alive Cookie: PREF=ID=...

Requte HTTP Get Spcifie quel hte est destine la requte Le client dsir maintenir la connexion Le cookie cr en 6/ est transmis au serveur

HTTP/1.1 200 Ok Connection Keep-Alive Last-modified: Tue, 23 Sep 2003 Expires: Sun, 17 Jan 2038

Le document a t trouv et suit les enttes Le serveur dsir maintenir la connexion Information concernant la gestion du cache pour le fichier retourn

Data

Le serveur envoie la suite du fichier dans des paquets HTTP dpourvues d'enttres

Connexion TCP entre le client et le serveur toujours ouverte

Laboratoire de transmission de donnes / EIG 18

Sbastien Contreras

Avril 2004

14

Encodage base 64

14.1.1 Quand lencodage base 64 est-il utilis ? Lencodage en base 64 est principalement utilis pour la transmission des fichiers binaires (images, excutables etc) par e-mail. Il est galement utilis pour masquer le mot de passe transmis lors de lauthentification Basic du protocole HTTP. Cet encodage ne consiste en aucun cas en un chiffrement des donnes. Il ne fournit quune autre manire de reprsenter les donnes. 14.1.2 Principe
6 bits 6 bits 6 bits 6 bits 1re tape 2me tape

buffer de 24 bits
8 bits 8 bits 8 bits

Chane de conversion : ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

Valeurs d'Index : A=0 , B=1 , ... , W=22 , Z=25 , l=37, n=39 , ... , 9=61 , +=62 , /=63

1re tape : remplir le buffer Le premier octet encoder est plac dans les 8 bits de poids forts dun buffer de 24 bits. Le deuxime octet est plac dans les 8 bits suivants et le troisime octet dans les 8 bits de poids faibles. Dans le cas o moins de 3 octets sont encoder, les bits vides du buffer sont remplis avec des 0. 2me tape : Conversion Les 6 bits de poids forts du buffer sont pris comme index dans la chane de conversion ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ . Le caractre dsign par lindex ainsi tabli est le premier caractre converti en base 64. Les 6 bits suivants sont pris comme index dans la chane de conversion. Le caractre dsign par lindex ainsi tabli est le deuxime caractre rsultant de la conversion. De mme pour les 2*6 bits restants. Remarque : Si moins de 3 octets sont encoder, cela ce traduit par le remplissage du buffer par des 0. Les groupes de 6 bits ainsi remplis sont convertis en = . 14.1.3 Exemple : Conversion de eig Caractre ASCII (dcimal) 8 Bits (binaire) e 101 01100101
25 = Z 2me tape 1re tape 0 1 10 0 1 0 1 0 1 1 0 1 0 0 1 0 1 1 0 0 1 1 1 e i g

i 105 01101001
22 = W 37 = l

g 103 01100111
39 = n

Aprs conversion au format base 64, eig devient ZWln 14.1.4 Failles lies lencodage en base 64 : Aprs conversion en base 64, les seuls caractres possibles sont ceux de la chane de caractres ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ . Cest en se basant sur cette constatation que les failles lies lencodage base 64 sont apparues. Forts de cette constatation, certains dveloppeurs nont pas intgrs leurs codes une gestion derreurs dans le cas o un caractre autre que ceux de la chane de caractres Base 64 se prsenterait.
Laboratoire de transmission de donnes / EIG 19

Sbastien Contreras

Avril 2004

14.1.4.1 Exploit dune faille lie lencodage Base 64 Hypothses : Un script sappuyant sur lauthentification Basic du protocole HTTP est utilis pour authentifier les clients. Le navigateur se connecte en passant par un proxy local (WebScarab [9] par exemple) afin de pouvoir modifier la requte. Droulement du scnario : 1/ Le navigateur va afficher une fentre demandant lutilisateur dentrer ses donnes dauthentification (Username/Password) 2/ Une fois les donnes entres, le navigateur les convertit au format base 64 et les envoie au proxy. 3/ Les donnes dauthentification encodes en base 64 sont modifies sur le proxy de faon y insrer un caractre autre que ceux gnrs par un encodage base 64 4/ Le proxy transmet la requte modifie au serveur Web 5/ Le serveur Web reoit les donnes dauthentification et les passe au script charg de valider ou dinvalider lauthentification. 6/ Le script va tre confront un cas non prvu et va planter Ce plantage va se traduire, selon la configuration matrielle et logicielle du serveur, par un crash du serveur, un gain de privilges etc

Laboratoire de transmission de donnes / EIG 20

Sbastien Contreras

Avril 2004

15

Conclusion A partir dune norme minimale HTTP 1.0, diverses volutions ont permis de dfinir la version 1.1 du protocole HTTP amliorant aussi bien les performance (connexions persistantes 7) que la scurit (Digest Authentication 11.2) et les mcanismes dj existants (cache 8, ngociation de contenu 9, Cookies 10 ). Cependant, de nouvelles fonctionnalits (Active X, applets Java, javascript, e-banking, webmail, administration dun serveur via HTTP, SOAP, XML, ) sont ajoutes tous les jours aux possibilits offertes par les navigateurs et serveurs Web, et chacune delles est une nouvelle source potentielle de failles. Toutes ces applications utilisent le port 80 et le protocole HTTP pour communiquer. Le niveau de complexit, en terme de nombre de fonctionnalits (plugins), atteint par les navigateurs et les serveurs Web est tel que ces applications (IE, Netscape, IIS, Apache) possdent toutes de nombreuses failles. Ces failles se situent pour la plupart au niveau applicatif et peuvent tre exploites par un mauvais contrle des paramtres reus par un script (Cross Site Scripting, Remote Directory Traversal), des buffers overflow (visant, par exemple, Windows Media Player, Internet Explorer ou mme des processus systme comme lsass.exe). De plus, la dmocratisation du firewall (souvent de type Personal Firewall pour les particuliers) laisse croire aux utilisateurs que leur poste est scuris et exempt de tout risque. Malheureusement, afin de permettre la navigation sur le Web, les firewalls laissent gnralement le port 80 ouvert et donc, une entre directe (..., P2P, IM, ...) sur le poste client. Les failles ne se situent pas au niveau du protocole HTTP mais au niveau des donnes transmises (cf. 14.1.4 faille base_64).

16

Sources

RFC 1945 Hypertext Transfer Protocol HTTP/1.0 http://www.faqs.org/rfcs/rfc1945.html RFC 2616 Hypertext Transfer Protocol HTTP/1.1 http://www.faqs.org/rfcs/rfc2616.html RFC 2617 HTTP Authentication: Basic and Digest Access Authentication http://www.faqs.org/rfcs/rfc2617.html RFC 2965 HTTP State Management Mechanism http://www.faqs.org/rfcs/rfc2965.html RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax http://www.faqs.org/rfcs/rfc2396.html Caching tutorial for web authors and webmasters http://www.mnot.net/cache_docs/ Ngociation de contenu http://www.apachefrance.com/Manuels/Apache_1.3_VF/content-negotiation.html Scurisation du trafic Web grce un proxy : Lexemple de Blue Coat http://www.td.unige.ch/wsh/blue_coat.pdf Site du proxy WebScarab http://www.owasp.org/software/webscarab.html

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

Laboratoire de transmission de donnes / EIG 21