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 découlé.
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 en 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 cookiesWindows 95/98/MEC:\Windows\Cookies\Windows NT 4C:\WINNT\Cookies\Windows 2000C:\Documents and Settings\<USER>\CookiesPar exemple, sur securiteinfo.com, nous utilisons 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.comwww.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.comContent-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.comConnection: keep-alive
Lecture du forum
GET /wwwboard/index.html HTTP/1.0
Accept: */*
Referer:
http://www.securiteinfo.comAccept-Language: fr
Accept-Encoding: gzip, deflate
User-Agent: Securiteinfo OS v1.01 (http://www.securiteinfo.com)
Host:
www.securiteinfo.comPragma: 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=uKtBwFxwConnection: keep-alive
Forwarded:
http://www.securiteinfo.comComme 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.frConnection: 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 GMTConnexion à 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.frPragma: no-cache
Cookie: PREF=ID=4179fbc62eb90f6c:LD=fr:TM=1023300641:LM=1023300641:S=EVRhsiQ8sCcConnection: 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 recoit 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, consultez la RFC
HTTP State Management MechanismLa 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.
</LI>
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
- Un site bien connu a stocké le couple login/mot de passe de l'authentification, en clair dans le cookie ! Nul besoin donc d'être un hacker hors du commun pour comprendre qu'il est enfantin d'exploiter ces informations. Il parait incroyable que des concepteurs de sites web mettent des données confidentielles en clair dans un cookie ! Webmasters, arrêtez le massacre ! Ne stockez plus d'informations confidentielles dans des zones non protégées/non chiffrées !
- Un autre superbe exemple d'une absence totale de protection des données sensibles : PHPNuke stocke le mot de passe Admin encodé en base 64 ! Rappelons que "base 64" n'est pas un algorithme de chiffrement, mais un algorithme d'encodage de données. Rien de plus simple donc, pour décoder ce mot de passe.
Référence : http://www.isecurelabs.com/article.php?sid=230
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.
- C'est le cas de Bluestone Sapphire/Web. Celui-ci utilise un numéro de session pour "authentifier" le visiteur. Le problème est que ce numéro de session est incrémenté de 1 à chaque nouvelle session ! Pour voler la session de la personne qui s'est connectée juste avant vous, il suffit de modifier le cookie : repérer où est stocké le numéro de session, le décrémenter de 1, sauvegarder la modification.
Référence : http://www.securiteam.com/exploits/2QUQ4QASAM.html
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
- Désactiver les cookies. Mais beaucoup de sites web ont besoin de cette fonctionnalité pour leur propre fonctionnement, pénalisant l'internaute qui ne supporte pas les cookies.
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.
- Ne jamais stocker les informations concernant l'authentification de l'internaute en clair ou encodé.
- Si vous utilisez un ID de session, ne jamais faire un ID incrémenté "simplement".
- Utilisez un ID de session aléatoire.
- Utilisez un ID de session a chaque requête HTTP.
- Utiliser un système de dé-login qui efface le cookie.
- Vérifiez que vos cookies ne sont pas sensible à une replay attack.
- Chiffrer les cookies : Un cookie peut être chiffré en partie ou en totalité. Mais attention, utilisez un chiffrement fort !
- Utilisez des protocoles sécurisés comme HTTPS.
- En aucun cas, un cookie ne doit être utilisé pour reconnaître automatiquement un internaute. Au mieux, un internaute devra, à chaque visite de votre site, s'authentifier pour recevoir un nouveau cookie.
[email]Arnaud Jacques[/email]
Accueil 
Ven 2 Fév - 12:06
