Société de Sécurité Informatique - Audit Firewall Appliance
La sécurité informatique - La sécurité des informations

Cookies et sécurité


Envoyer cet article par Email !Imprimer cet article !Exporter cet article en PDF !FacebookTwitterGoogle Bookmarks

Introduction


Depuis leur apparition, les cookies ont été contestés. Cela a débuté par les problèmes de violation de la vie privée, suivi de prêt par le non-anonymat que cela a engendré.
Maintenant, de nouveaux évènements ont démontré la faiblesse des cookies au niveau de la sécurité. Nous allons vous expliquer de quoi il retourne.

Qu'est-ce que c'est ?


Un cookie est un petit fichier texte, qui est stocké par un site web sur votre disque dur. Ce stockage est réalisé par votre navigateur. Cela est utilisé par le site web que vous visitez pour vous "reconnaître". Aussi, quand plusieurs jours après votre visite, vous revenez sur le même site, celui-ci demandera votre cookie, et s'il est encore présent sur votre disque dur, le site web lira les informations contenues dans le cookie et vous "reconnaîtra". Je mets le verbe reconnaître entre guillemets, car il s'agit d'une pseudo-authentification...

Les cookies sont généralement stockés dans :

OSLieu de stockage des cookies
Windows 95/98/MEC:\Windows\Cookies\
Windows NT 4C:\WINNT\Cookies\
Windows 2000C:\Documents and Settings\<USER>\Cookies

Par exemple, sur securiteinfo.com, nous utilisions un cookie pour le forum. Si vous envoyez un message dans le forum, en remplissant votre pseudo (champs "Nom"), et éventuellement les autres champs ("email", "URL", etc...), ces informations seront stockées dans un cookie. Ainsi, quand vous reviendrez voir le contenu du forum, le site Securiteinfo.com vous "reconnaîtra" et remplira pour vous les divers champs que vous aviez rempli auparavant.

Voici en exemple, le cookie du webmaster de securiteinfo.com pour le forum :

name
Webmaster
www.securiteinfo.com/
0
610742400
29561850
838443904
29488426
*
email
webmaster@securiteinfo.com
www.securiteinfo.com/
0
610742400
29561850
900633904
29488426
*
url
http%3A//www.securiteinfo.com
www.securiteinfo.com/
0
610742400
29561850
1201873904
29488426
*
url_title
Securiteinfo.com
www.securiteinfo.com/
0
610742400
29561850
1189853904
29488426
*
img
http%3A//www.securiteinfo.com/banner6.gif
www.securiteinfo.com/
0
610742400
29561850
1285293904
29488426
*
magic
uKtBwFxw
www.securiteinfo.com/
0
2355775104
29561851
1289993904
29488426
*

Comme vous le voyez, on y retrouve les champs "name", "email", "url", "url_title", "img".Le champs "magic" est la signature de mon identité.

Comment cela fonctionne-t-il ?


Comment mon navigateur peut envoyer un cookie au serveur ? Comment un site web peut envoyer un fichier texte et dire au navigateur de l'enregistrer ? La réponse est simple : Le cookie est envoyé, non pas comme une pièce jointe d'email, mais placé dans l'entête HTTP de la requête. Voici en détail ce qui se passe :


Création d'un cookie à l'initiative du navigateur



Envoi d'un message sur le forum Securiteinfo.com


POST /wwwboard/fd_board.cgi HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Referer: http://www.securiteinfo.com/wwwboard/
Accept-Language: fr
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Host: www.securiteinfo.com
Content-Length: 199
Pragma: no-cache
Cookie: name=Webmaster; email=webmaster@securiteinfo.com; url=http%3A//www.securiteinfo.com; img=http%3A//www.securiteinfo.com; url_title=Securiteinfo.com
Connection: keep-alive

Lecture du forum


GET /wwwboard/index.html HTTP/1.0
Accept: */*
Referer: http://www.securiteinfo.com
Accept-Language: fr
Accept-Encoding: gzip, deflate
User-Agent: Securiteinfo OS v1.01 (http://www.securiteinfo.com)
Host: www.securiteinfo.com
Pragma: no-cache
Cookie: name=Webmaster; email=webmaster@securiteinfo.com; url=http%3A//www.securiteinfo.com; url_title=Securiteinfo.com; img=http%3A//www.securiteinfo.com/banner6.gif; magic=uKtBwFxw
Connection: keep-alive
Forwarded: http://www.securiteinfo.com

Comme vous le voyez, le cookie étant un fichier texte, il est placé dans l'entête HTTP, champs "Cookie". Et comme vous l'avez remarqué, le cookie est EN CLAIR ! Nous y reviendrons plus tard :)


Création d'un cookie à l'initiative du serveur



Un exemple : Google.fr

Connexion vers www.google.fr, la première fois (c'est à dire sans cookie)


GET / HTTP/1.0
Accept: */*
Accept-Language: fr
Accept-Encoding: gzip, deflate
User-Agent: Securiteinfo OS v1.01 (http://www.securiteinfo.com)
Host: www.google.fr
Connection: keep-alive

Réponse de Google.fr


HTTP/1.1 200 OK
Content-Length: 1546
Server: GWS/2.0
Date: Wed, 05 Jun 2002 18:10:41 GMT
Content-Encoding: gzip
Content-Type: text/html
Cache-control: private
Set-Cookie: PREF=ID=4179fbc62eb90f6c: LD=fr: TM=1023300641: LM=1023300641: S=EVRhsiQ8sCc; domain=.google.fr; path=/; expires=Sun, 17-Jan-2038 19:14:07 GMT

Connexion à nouveau sur www.google.fr (avec cookie cette fois-ci)


GET / HTTP/1.0
Accept: */*
Accept-Language: fr
Accept-Encoding: gzip, deflate
User-Agent: Securiteinfo OS v1.01 (http://www.securiteinfo.com)
Host: www.google.fr
Pragma: no-cache
Cookie: PREF=ID=4179fbc62eb90f6c: LD=fr:TM=1023300641: LM=1023300641: S=EVRhsiQ8sCc
Connection: keep-alive

Comme on le voit, lorsque le serveur reçoit une requête HTTP vierge de tout cookie, il en crée un et le transmet avec la réponse grâce à la fonction Set-Cookie. Le client reçoit la réponse, crée le cookie dans un fichier texte, sur votre disque dur. A la prochaine connexion, il transmettra à Google.fr les informations contenues dans le cookie.

Si vous souhaitez plus d'élément sur l'aspect purement technique des cookies, consultezla RFC HTTP State Management Mechanism

La sécurité


Les cookies contiennent des données personnalisées de votre compte, de votre ordinateur. Les cookies sont donc des données sensibles d'un point de vue de la sécurité. Ils faut donc les considérer comme des données personnelles que personne ne doit obtenir. Ce n'est donc pas un hasard s'ils sont stockés dans C:\Documents and Settings sous Windows 2000.
Nous allons donc faire le tour de l'aspect sécurité des cookies.

Vol de cookies



Le but du hacker, est donc généralement de voler le cookie de sa victime pour en exploiter le contenu.
Comme nous l'avons vu, en théorie, un cookie associé à un site web ne peut pas être envoyé à un autre site web. Malheureusement, un certain nombre de failles permettent de voler des cookies.

Vol par accès physique à la machine


Si le hacker a accès physiquement à la machine, rien de plus simple que de récupérer les cookies ! Il va dans le répertoire de stockage des cookies en fonction du système d'exploitation (voir tableau plus haut) et copie les cookies sur disquette...
La station est vérouillée ? L'attaquant n'a pas les droits d'admin ? Trinux permet de prendre la main sur la machine locale en rebootant sur disquette ou CD. Il ne reste plus qu'à "mounter" la partition et récupérer les cookies qui vont bien :)

Vol par sniffing / man in the middle


Comme nous l'avons vu, les cookies passent par les requêtes HTTP. Si l'attaquant peut intercepter les requêtes HTTP, soit à l'aide d'un sniffer, soit par attaque par le milieu, il peut donc récupérer tous les cookies sans aucun problème. A condition bien sur que le flux HTTP ne soit pas chiffré (HTTPS, VPN...).

Vulnérabilité du navigateur


Cette usine à gaz qu'est le navigateur, de plus en plus compliqué à chaque nouvelle version, comporte un nombre de failles impressionnant. Parmi toutes ces failles, il y en a certaines qui concernent tout particulièrement les cookies.


Exploitation des cookies volés



Une fois qu'un hacker a votre cookie, il peut l'exploiter. Voici un petit panorama de ce qu'il peut faire...

Récupération des données d'authentification


Replay attacks


Les cookies sont en général utilisés pour reconnaître l'internaute qui visite le site (je n'ose pas parler d'authentification). Un exploit très classique et très facile est le replay attack. Il s'agit de rejouer la session de connexion au site. Si le cookie n'est pas écrit pour empêcher cette attaque, alors l'attaquant peut utiliser le cookie de sa victime pour être reconnu comme celle-ci par le site web. En général, le simple fait de reprendre tel quel le cookie de sa victime et de le mettre dans ses propres cookies permet à l'attaquant de se faire passer pour elle.

Modification de cookies pour prendre l'identité de la victime


Quelque fois, une attaque par replay ne fonctionne pas telle quel. Il faut modifier quelque peu le cookie pour voler la session.

Modification de cookies pour obtenir des droits privilégiés


La modification du cookie peut être effectuée pour ne pas prendre l'identité de la victime, mais prendre directement les droits de la victime.

Les solutions



Côté client




Côté site web



La sécurité au niveau des cookies est à la charge du webmaster. Lui seul doit prendre en compte la sécurité de son site et des internautes qui le visite.

Arnaud Jacques
15 Juillet 2002

Ils nous font confiance
© 2014 - Tous droits réservés - SecuriteInfo.com