Détecter et analyser les cookies et autres traceurs

Magazine
Marque
MISC
Numéro
81
Mois de parution
septembre 2015
Spécialité(s)


Résumé

Le traçage de la navigation des internautes pour alimenter les bases de données du monde de la publicité ciblée s'opère par différentes techniques qui sont présentées dans la première partie de cet article : pixels invisibles, cookies HTTP, cookies flash ou stockage web local. La deuxième partie décrit au lecteur des outils simples et une méthodologie qui lui permettront de le détecter et de l'analyser lui-même sur ses sites internet préférés. Elle explique également comment les acteurs publicitaires parviennent aujourd'hui à rompre le présumé anonymat des internautes non connectés pour leur adresser des publicités personnalisées par voie électronique, téléphonique ou postale (« cross canal ») ou sur leurs autres terminaux (« cross device »). La partie 3 de cet article propose des moyens de protection contre ces techniques de traçage. Enfin, en guise d'appendice, quelques aspects liés à la sécurité des cookies sont abordés. Cet article s’appuie en partie sur l’expérience du service des contrôles de la CNIL sur ces sujets.


Body

1. Principaux traceurs utilisés dans la publicité ciblée

Il existe plusieurs manières de tracer un internaute au cours de sa navigation sur le web. Les méthodes les plus utilisées ont été rencontrées par la CNIL lors de contrôles effectués ces dernières années auprès d’acteurs majeurs de l'Internet, que ce soit des sites éditeurs, annonceurs ou des sociétés spécialisées dans la publicité ciblée.

1.1 Pixel invisible

La technique dite du « pixel invisible » consiste à appeler une image, hébergée sur un serveur tiers, à la taille de 0 ou de 1 pixel, donc invisible de l’internaute. Lors de cet appel, des informations sont transmises en paramètre de la requête HTTP/GET correspondante.

Exemples de tag [portion de code HTML ou JavaScript] incluant un pixel invisible :

<img src="http://serveur-de-tracking.com?&img=d690a7357b.png" style="position:absolute; visibility:hidden">

 

<img src="http://serveur-de-tracking.com?&img=d690a7357b.png" style="display:none">

 

<img src="http://serveur-de-tracking.com?pixel.png?APN=8186779241047110843&pid=CAESEAZY8yBmmTLHS_0bBfHimto width="0" height="0">

Dans ces exemples, en ouvrant la page web ou le courrier électronique qui contiendrait un de ces tags HTML, le navigateur de l’internaute effectue une requête de type GET vers le serveur-de-tracking.com. Il transmet alors un paramètre : un nom d’image (d690a7357b.png) ou un contenu de variable (pid=CAESEAZY8yBmmTLHS_0bBfHimto). Ce paramètre unique, permet alors de « reconnaître » l’internaute et donc de savoir qu'il a consulté telle partie d'une page internet ou qu'il a ouvert tel e-mail publicitaire.

1.1.1 Pixel invisible et dépôt de cookie

En réponse, le serveur web peut déposer un ou plusieurs cookies via l'instruction (en-tête) « set-cookie » du protocole HTTP. Dès lors, à chaque fois que l’internaute se rendra sur un site web contenant un tag redirigeant vers le domaine serveur-de-tracking.com, il sera pisté. Nous verrons, dans la partie cross-canal, comment les sites visités obtiennent alors l’adresse électronique de l’internaute, à des fins de sollicitation commerciale.

Cette technique requiert d’utiliser des cookies.

1.2 Cookies HTTP

Le cookie HTTP reste la technique la plus utilisée pour tracer les internautes.

Un cookie est défini dans la RFC 2965 [RFC6265] comme étant une suite d’informations envoyée par un serveur web à un client HTTP. Ce dernier retourne le contenu du cookie lors de chaque interrogation d’un serveur web associé au même nom de domaine (sous certaines conditions).

Les cookies ont été initialement prévus et utilisés à des fins techniques ou fonctionnelles. Ils permettent par exemple au protocole HTTP (nativement « stateless ») d’avoir la possibilité de gérer les sessions et de permettre certaines fonctionnalités. Cependant, leur usage initial a progressivement été complété par une utilisation à des fins de traçage publicitaire, car les cookies peuvent aussi stocker des informations relatives à la navigation de l’internaute ou un identifiant de « tracking ».

Le cookie se présente aujourd’hui sous différentes formes en fonction des navigateurs (cf. article de Cyrille Aubergier dans le MISC précédent) :

- Internet Explorer enregistre chaque cookie dans un fichier texte différent ;

- Mozilla Firefox et Google Chrome enregistrent les cookies dans une base de données SQLite ;

- Opera enregistre tous ses cookies dans un seul fichier et le chiffre — ce que ne font pas les trois autres.

1.3 Local Shared Objects (Cookies Flash)

Les local shared objects [LSO], connus également sous le nom de « cookies flash », sont des données enregistrées sur l’ordinateur de l'internaute, lors de l’exécution d’applicatifs Flash (Adobe Flash Player et Macromedia Flash MX Player).

Par défaut, l’applicatif Flash peut écrire sur le terminal de l’utilisateur sans avoir requis préalablement le consentement de l’utilisateur.

Où trouver les cookies Flash sur mon terminal :

  • Windows :
    • %APPDATA%\Macromedia\Flash Player\#SharedObjects\
    • %APPDATA%\Macromedia\Flash Player\macromedia.com\
  • Mac OS X :
    • ~/Library/Preferences/Macromedia/Flash Player/#SharedObjects/
    • ~/Library/Preferences/Macromedia/Flash Player/macromedia.com/
  • Linux/Unix :
    • ~/.macromedia/Flash_Player/#SharedObjects/
    • ~/.macromedia/Flash_Player/macromedia.com/
  • Linux/Unix (utilisant le logiciel libre Gnash, en remplacement de Flash Player) :
    • ~/.gnash/SharedObjects/
  • Dans le cas de chrome (Flash Player est intégré via Pepper Flash (PPAPI) :
    • Windows : %localappdata%\Google\Chrome\User Data\Default\Pepper Data\Shockwave Flash\WritableRoot\#SharedObjects
    • Mac OS X : ~/Library/Application Support/Google/Chrome/Default/Pepper Data/Shockwave Flash/WritableRoot/#SharedObjects/
    • Linux/Unix : ~/.config/google-chrome/Default/Pepper Data/Shockwave Flash/WritableRoot/#SharedObjects/

Les cookies flash peuvent aussi être affichés dans un navigateur via l'URL suivante (qui permet aussi de régler les paramètres du FlashPlayer) : http://www.macromedia.com/support/documentation/fr/flashplayer/help/settings_manager07.html.

Le processus d’une application Flash lit directement ces cookies dans les répertoires où ils sont stockés.

À noter : Adobe Flash propose un « mode privé » où les cookies Flash ne sont pas sauvegardés. Celui-ci s’active dans les paramètres Flash lorsque l'on se trouve sur une page contenant un applet Flash.

1.4 Local Storage/Stockage web local (HTML5)

HTML5 apporte une nouveauté par rapport à ses prédécesseurs : la possibilité de stocker des données dans le navigateur sans utiliser de cookies. Cette technique, appelée « stockage web local » (ou local storage), permet de sauvegarder des volumes de données plus importants qu’avec les cookies (de l’ordre de 5 Mo à 10 Mo pour l’instant contre quelques kilo-octets pour les cookies).

Il existe deux types de stockage web local : le stockage local et le stockage de session, équivalent respectivement aux cookies persistants et aux cookies de session.

Par défaut, les informations contenues dans la base locale ne sont pas systématiquement renvoyées au serveur web à chaque requête. Elles sont cependant récupérables sur demande (par exemple via des instructions JavaScript).

Dans le cas de Mozilla Firefox, ces données sont stockées dans une base de données de type SQLite, nommée webappsstore.sqlite. Avec un logiciel permettant de lire une base de données SQLite, il est possible de consulter ces cookies (par exemple, avec l'extension Firefox SQLite Manager).

À ce jour, peu de sites utilisent cette technique pour identifier les internautes.

1.5 Fingerprinting

Le fingerprinting consiste à récupérer une « empreinte » du navigateur de l’internaute afin de l’identifier lors de connexions ultérieures.

Le fingerprinting fait l’objet d’un article dédié dans ce dossier.

2. Observer le tracking

La méthodologie décrite dans cette partie vise à observer et analyser les traceurs de type « pixels invisibles » et « cookies HTTP » qui demeurent encore de loin les plus utilisés.

Pour les besoins de l’article, nous avons réalisé un parcours de navigation sur Internet comprenant d'abord l’inscription sur quatre sites web d’éditeurs ou d’annonceurs ; puis la navigation sur deux sites de e-commerce avec la mise au panier d’articles ; enfin, la navigation sur un site d’annonceur avec affichage de publicités ciblées. L’objectif est d’illustrer le fait que certains aspects du traçage opéré par les publicitaires au moyen de cookies HTTP peuvent être simplement observés. La méthodologie étant reproductible et basée sur des extensions du navigateur Mozilla Firefox, le lecteur est invité à se livrer à la même expérience.

Les cookies déposés durant ce parcours, au nombre de 505, ont été examinés et sauvegardés avec l’extension Cookie Manager + [CookieManager +]. Par ailleurs, les en-têtes HTTP des échanges entre notre navigateur et les serveurs web distants ont été capturés au moyen de l’extension Live HTTP Headers [LiveHTTPHeaders]. Cette capture permet par exemple de constater d’autres transmissions de données, connexes à celles réalisées par les cookies :

- les transmissions opérées en cas d'appel de pixels invisibles ;

- le chaînage des appels de serveurs publicitaires et les dépôts/lectures de cookies qui en résultent dans le cadre d’une enchère publicitaire (RTB, voir article dédié dans ce dossier) ;

- les partages de cookies (Cookie Matching).

2.1 « Voir l’invisible » : la visualisation graphique avec Cookie Viz

La CNIL met à disposition de tous, sous licence libre (GPLv3), un outil de visualisation qui identifie en temps réel les requêtes HTTP vers des serveurs tiers et les cookies déposés par ces serveurs. Des alternatives à cet outil existent, comme Lightbeam. L’avantage majeur de CookieViz sur les autres outils similaires est qu’il est capable de visualiser les cookies de l'ensemble des navigateurs.

Concrètement, CookieViz analyse les interactions entre votre ordinateur, votre navigateur et les sites et les serveurs distants contactés au cours de la navigation.

 

CookieViz-1

 

Fig 1 : CookieViz permet d’afficher les acteurs tiers contactés lors de la visite d’un site web.

2.2 L’analyse des caractéristiques des cookies avec Cookie Manager +

Pendant la vingtaine de minutes qu’a duré l’expérience, 505 cookies ont été déposés. La très grande majorité (378) sont des cookies tiers (« third party »), déposés par des serveurs web de domaines distincts du site web visité. Ils sont appelés suite à l’exécution de tags (images, code JavaScript) fournis par les prestataires et intégrés au code HTML de la page web. Une minorité (127) sont des cookies déposés et lus par les serveurs web des sites visités (« first party »). Cependant, certains de ces cookies peuvent avoir une finalité publicitaire (certains gros sites ont leur propre régie) ou être des « faux cookies internes », c’est-à-dire des cookies dont le domaine est celui du site, mais qui sont liés à des prestations réalisées par des tiers. C’est par exemple le cas des cookies de mesure d’audience « Google Analytics », présents sur la majorité des sites internet, et dans notre expérience, sur les 7 sites visités. Ils ont pour noms : _ga, _gat, _utma, _utmb, _utmc, _utmt, _utmv et _utmz. Ces derniers sont lus par le serveur web du site, mais d’autres requêtes HTTP transmettent leur contenu (par passage en paramètre) aux serveurs de Google. Un blocage des cookies tiers est donc inefficace pour bloquer ce type de cookies.

Certains des cookies tiers qui ont été déposés ont des finalités liées aux boutons de partage sur les réseaux sociaux ou à la mesure d’audience. La majorité de ces cookies semble en revanche avoir des finalités publicitaires et certains contiennent des identifiants uniques du navigateur de l'internaute. Si les noms de domaine peuvent faire apparaître des noms d’acteurs publicitaires, les noms des cookies peuvent également être parlants.

Ainsi, une simple recherche des cookies dont le nom contient la chaîne « uid » (pour « user id ») en fait apparaître 53. En voici quelques-uns :

 

Cookies-1

 

Fig 2 : De nombreux cookies ont pour nom « …uid… ».

Comme on peut le constater, ils contiennent en général des numéros identifiants uniques du navigateur de l’utilisateur en général au format décimal, hexadécimal ou chiffré. L’acteur publicitaire « reconnaît » ainsi le navigateur de l’utilisateur grâce à ce numéro, les données de navigation et d’analyse étant stockées en base, côté serveur.

Mais certaines régies peuvent faire le choix de stocker également une synthèse du profil publicitaire de l’internaute dans les cookies, côté client.

Ils sont en général dans des formats encodés :

Name: evt

Path: /

Content: *1S%2fNl8ZLCh3bw%2fvduq5tHqo1uw%2biQjjzBVvt2YCBDgp4%3d

D’une part, si les numéros d’identification de l’internaute sont propres à chaque acteur publicitaire, le cloisonnement des lectures et dépôts de cookies étant garanti par la « same-origin-policy » du navigateur, on peut remarquer que certains cookies de domaines différents utilisent le même identifiant. Comme évoqué dans l’article sur le RTB de ce dossier, c’est une conséquence du partage de cookies (« cookie matching » ou « cookie syncing ») sur laquelle nous reviendrons. À ce stade, ce point peut être facilement constaté en opérant un tri dans la colonne « Content » de Cookie Manager+ :

 

Cookies-2

 

Fig 3 : Illustration du «cookie matching».

D’autre part, l’examen des durées de vie des cookies peut être également un indice sur une finalité de traçage dans le temps. Dans notre expérience, 219 cookies (soit 43 %) ont une durée de vie supérieure ou égale à un an, certains pouvant avoir des durées très longues :

Name: uids

Path: /

Content: @DDF>B@NKu@j`BDz{TMIQuFgH{|@DCF>>

Content raw: @DDF>B@NKu@j`BDz{TMIQuFgH{|@DCF>>

Expires: dim. 27 sept. 2037 02:00:13 CEST

2.3 Pour aller plus loin : l’analyse des en-têtes des requêtes HTTP

2.3.1 Dépôts et lectures de cookies de tracking dans les en-têtes HTTP

Les dépôts et lectures de cookies peuvent facilement être observés dans l’examen des en-têtes HTTP. Les dépôts et modifications de cookies apparaissent par le biais de l’instruction « Set-cookie » de la réponse du serveur web. Les cookies associés à un nom de domaine et déjà présents sur le navigateur sont systématiquement fournis (modulo des restrictions éventuelles sur les sous-domaines) dans le champ « Cookies » du navigateur. Par exemple, voici deux requêtes HTTP vers un serveur publicitaire :

http://ib.adnxs.com/getuidnb?http%3A%2F%2Fp.crm4d.com%2Fsync%2Fappnexus%2Fs.gif%3Fuid%3D%24UID

 

GET /getuidnb?http%3A%2F%2Fp.crm4d.com%2Fsync%2Fappnexus%2Fs.gif%3Fuid%3D%24UID HTTP/1.1

Host: ib.adnxs.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0

[…]

Referer: http://www.monsite-ecommerce.com/

Connection: keep-alive

 

HTTP/1.1 302 Found

[…]

Expires: Sat, 15 Nov 2008 16:00:00 GMT

P3P: policyref="http://cdn.adnxs.com/w3c/policy/p3p.xml", CP="NOI DSP COR ADM PSAo PSDo OURo SAMo UNRo OTRo BUS COM NAV DEM STA PRE"

X-XSS-Protection: 0

Location: http://ib.adnxs.com/bounce?%2Fgetuidnb%3Fhttp%253A%252F%252Fp.crm4d.com%252Fsync%252Fappnexus%252Fs.gif%253Fuid%253D%2524UID

Content-Type: text/html; charset=utf-8

Set-Cookie: sess=1; Path=/; Max-Age=86400; Expires=Fri, 03-Jul-2015 20:00:16 GMT; Domain=.adnxs.com; HttpOnly

Set-Cookie: uuid2=66106801265861589; Path=/; Max-Age=7776000; Expires=Wed, 30-Sep-2015 20:00:16 GMT; Domain=.adnxs.com; HttpOnly

Date: Thu, 02 Jul 2015 20:00:16 GMT

Content-Length: 0

 

On peut observer qu’en réponse à cette requête, deux cookies sont déposés, l'un d'eux contenant un identifiant unique (uuid2). Lors de la requête suivante vers la régie, les cookies seront donc « servis » par le biais de l'en-tête « cookie » des requêtes HTTP :

http://ib.adnxs.com/getuid?http://mapping.nxtck.com/rtb/um?n=msn&gid=$UID&uuid=e4647673-7aac-4a24-94f6-8103db8ada8d&cb=1123713856&redir=http%3A%2F%2Fib.adnxs.com%2Fseg%3Fadd%3D209359%2526redir%253Dhttp%25253A%25252F%25252Fib.adnxs.com%25252Fsetuid%25253Fentity%25253D70%252526code%25253De4647673-7aac-4a24-94f6-8103db8ada8d

 

GET /getuid?http://mapping.nxtck.com/rtb/um?n=msn&gid=$UID&uuid=e4647673-7aac-4a24-94f6-8103db8ada8d&cb=1123713856&redir=http%3A%2F%2Fib.adnxs.com%2Fseg%3Fadd%3D209359%2526redir%253Dhttp%25253A%25252F%25252Fib.adnxs.com%25252Fsetuid%25253Fentity%25253D70%252526code%25253De4647673-7aac-4a24-94f6-8103db8ada8d HTTP/1.1

Host: ib.adnxs.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0

Accept: image/png,image/*;q=0.8,*/*;q=0.5

Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

Referer: http://www.monsite-ecommerce.com/

Cookie: sess=1; uuid2=66106801265861589

Connection: keep-alive

2.3.2 La mise en commun d’identifiants (le « cookie syncing » ou « cookie matching »)

Une recherche dans les captures HTTP de l'identifiant cookie observé précédemment et commun à plusieurs acteurs publicitaires, montre plusieurs requêtes. Par exemple celle-ci :

http://map.sddan.com/MAP.d?mn=nexus&mv=8186779241047110843

 

GET /MAP.d?mn=nexus&mv=8186779241047110843 HTTP/1.1

Host: map.sddan.com

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0

Accept: image/png,image/*;q=0.8,*/*;q=0.5

Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

Referer: http://www.monsite-ecommerce.com/

Cookie: SDDAN=U9RISYRH8PSAAOH4IZXAXWA5SURLYBF7

Connection: keep-alive

 

HTTP/1.1 200 OK

Server: nginx/1.8.0

Date: Thu, 02 Jul 2015 20:00:17 GMT

Content-Type: image/gif

Transfer-Encoding: chunked

X-Powered-By: PHP/5.4.41-0+deb7u1

Set-Cookie: map_nexus=8186779241047110843; expires=Sun, 26-Jun-2016 20:00:17 GMT; domain=.sddan.com

Via: 1.1 google

Expires: Thu, 02 Jul 2015 20:00:17 GMT

Cache-Control: private

On peut voir que cette requête transmet, par passage en paramètre de l'URL, l'identifiant « 8186779241047110843 » et qu'en retour, le serveur web dépose un cookie avec le même identifiant, et cette fois associé à son nom de domaine.

On peut également observer, dans le fichier de capture, que de nombreuses autres requêtes transmettent cet identifiant en paramètre, mais sans dépôt de cookie en retour.

Dans tous les cas, il s’agit de partage/synchronisation de cookies opérés dans le cadre d’enchères publicitaires — le « matching » étant réalisé côté client ou côté serveur. Dans ce dernier cas, des tables de correspondance entre les identifiants des différentes régies et acteurs sont construites au niveau des échangeurs et/ou des régies elles-mêmes (ou d'autres acteurs intermédiaires). Cela n’est pas sans implication sur l’ampleur du traçage et sur le lien qui peut désormais être fait entre les différentes données collectées par les différents acteurs publicitaires. En effet, le cloisonnement des identifiants par acteur publicitaire, qui prévalait avant l'avènement du RTB, n'a aujourd'hui plus cours (voir article sur le RTB dans ce dossier).

2.3.3 Mise en évidence du RTB par le chaînage des requêtes

L'observation du chaînage des requêtes, par le biais du « Referer » du protocole HTTP qui indique la requête HTTP précédente ayant appelé celle-ci, peut servir à mettre en évidence les appels générés lors des enchères publicitaires (RTB) décrites dans un article de ce dossier. Par exemple la requête suivante :

http://bid.g.doubleclick.net/xbbe/invitepixel/set_partner_uid?partnerID=79&partnerUID=85eeb731c50701a62fae6f1bb96edebe&sscs_active=1

GET /xbbe/invitepixel/set_partner_uid?partnerID=79&partnerUID=85eeb731c50701a62fae6f1bb96edebe&sscs_active=1 HTTP/1.1

Host: bid.g.doubleclick.net

[...]

Referer: http://loadeu.exelator.com/load//net.php?n=eJyNUctuwjAQ%2FBUUVbnVSSjPFhNVglbcWqGekWMvzkLiWPGSpn9fE1JEb9x2ZleehxdY6kEOqHPiQRIMvlFR3k2uljzIiexzFDnQJRh6tNhCwdA0SFCCQsFkVfot7ayoyUC9O6FK%2B3mz4tN52IMvj2ZjgGz6lMhxPI0TMRnuBUz2SZbNJ6Agg9A56XZCEjbAk2C5iLy55cLJGi0N6McCDwhaig6iERf2v00lHDsdGbQWahSmM%2Fd6UghGwubzZtxC3aAE5hoZvQO9YUFQg1q3diVIpB%2FXAEk8Cz9OWYEuv%2BLLNV%2F7KgTBFrQLBt7rxdBycVehmDGhTOs6ixrI12aytF8WlVClT3F%2Bv6q7kzMVpZYP41GoeZyMwgz5gy81PPD42tRd0rJkmqnKhwJZoDwyAxR1H5vqqtIF7AwqflGHUJT2padleYuc%2FJP9BQxvx8w%3D&h=3ba0f80e64e874b2dd09ead22a236ef1&ver=2

Cookie: id=22d79de510020013||t=1435867217|et=730|cs=002213fd486980abab9dadcba2

Connection: keep-alive

Il s'agit d'une requête à destination du sous-domaine « bid » (bid=enchère) de « g.doubleclick.net », domaine de la régie publicitaire de Google. Elle est initiée à la suite d’une requête vers un sous-domaine de « exelator.com » qui apparaît dans le « Referer » et qui appartient à la société Exelate. Celle-ci fournit une offre de place des marchés publicitaires (marketplace ou échangeur). L'examen des requêtes met en évidence d'autres requêtes avec le même « Referer » et à destination d'autres acteurs publicitaires.

2.3.4 L’adresse électronique comme clé de voûte de l'identification : du « cross canal » au « cross device »

La navigation de l'internaute peut désormais être associée à son adresse électronique, rompant ainsi l’ « anonymat » (en fait pseudonymat) annoncé dans la plupart des politiques « cookies » des sites web. D’ailleurs, même sans l'utilisation des techniques décrites dans ce paragraphe, cet « anonymat » relatif du traçage opéré par les cookies peut être rompu par d’autres manières (cf. par exemple [MISC-Analyse]).

Le retargeting ou le re-ciblage publicitaire sur des articles consultés par l'internaute sur un site sur lequel il n’est pas inscrit est désormais possible par courriel (« e-mail retargeting »). Il recevra alors des publicités par e-mail pour des produits similaires ou semblables à ceux qu'il a consultés sur des sites internet.

L’internaute pourra par ailleurs être contacté sur un autre canal (cross canal) si la régie publicitaire dispose d’une base plus complète à même d'associer à l'adresse e-mail, l’adresse postale de l’internaute ou son numéro de mobile, ou si elle paye une prestation « d’enrichissement de base » auprès d’une société spécialisée.

Cette identification de l’internaute est réalisée par des dépôts de cookies contenant un haché (en général SHA1 ou MD5) de son adresse électronique. Ce dépôt s’effectue soit à l’ouverture d’un courrier électronique, soit à la connexion sur un site partenaire (« matching partner ») qui vend cette possibilité d’identification de l’internaute. Ce second cas est expliqué dans les schémas suivants :

 

Utilisateur-1

 

 

Utilisateur-2

 

 

Utilisateur-3

 

Les captures HTTP réalisées mettent en évidence des requêtes et dépôts de cookie du domaine « emailretargeting.com ».

Set-Cookie: etuix=FVO9KtSlVspzVohjEoHNrb71FLhCPd9WYSont0N8uUO1r7CPikBnEA--; expires=Tue, 29 Dec 2015 20:12:07 GMT; path=/; domain=.emailretargeting.com

Les hachés d’adresses électroniques peuvent aussi être utilisés pour relier les différents terminaux d'un même utilisateur à des fins de prospection publicitaire (PC personnel, professionnel, smartphone, tablette, etc.). C’est ce qu’on appelle le « cross device ».

3. Quelques solutions simples pour arrêter (limiter) le traçage

On peut parfois (souvent) lire dans la rubrique cookies des sites internet que l'utilisateur peut s'opposer aux dépôts de cookies en les bloquant via les paramètres de son navigateur, mais qu'après cette action, certaines fonctionnalités du site (souvent essentielles comme la connexion au compte) seront inopérantes. C'est une incitation habile à accepter tous les cookies…

Voici donc quelques solutions simples, non exclusives, qui limitent fortement le traçage sans entraver la navigation de l'internaute :

1. Utilisation du mode de  navigation privée (« ne jamais conserver l'historique » sous Mozilla Firefox). Cela limite la « mémoire » du traçage à une session seulement.

2. Blocage des cookies tiers dans les paramètres du navigateur. Les cookies tiers étant dans la quasi-totalité des cas non techniques et non fonctionnels, cela n'entravera que très peu l'expérience de navigation. À noter que cette solution ne protège cependant pas des « faux cookies first party » comme ceux de Google Analytics par exemple.

3. Utilisation d'extensions limitant ou bloquant les traceurs, par exemple : DoNotTrackMe, Disconnect, Ghostery ou AdBlockEdge (qui bloque aussi l'affichage des publicités).

4. Limitation du traçage dans les paramètres d'Adobe Flash.

Pour plus de détails, le lecteur pourra se reporter à une rubrique dédiée sur le site Internet de la CNIL [CNIL-CONSEILS].

Enfin, l'e-mail devenant la clé de voûte d'un traçage plus étendu, et même si cela est plus complexe, car cela nécessite de posséder ou d'acheter son propre nom de domaine, il est recommandé à l'internaute qui souhaite vraiment se protéger d'utiliser un alias de son adresse e-mail propre à chaque site. Par exemple, sur le site « monjournal », on pourra fournir l'alias (redirection e-mail) « monjournal@domain » où « domain » correspond à notre nom de domaine. Cela permet de plus de détecter une revente indue de l'e-mail à un spammeur et de couper la redirection si nécessaire...

4. Appendice : quelques remarques sur la sécurité et les cookies

4.1 Les cookies apprécient aussi l’HTTPS − de l’utilité de l’attribut « secure »

La RFC 6265 définit l’attribut secure pour les cookies : cet attribut peut-être associé indifféremment à chaque cookie. Lorsqu’il est activé pour un cookie, ce dernier est transmis uniquement à travers un protocole sécurisé.

Extrait de la RFC 6265

If the cookie's secure-only-flag is true, then the request-uri's scheme must denote a "secure" protocol (as defined by the user agent).

Certains sites ne chiffrent pas les données (potentiellement personnelles ou sensibles) contenues dans des cookies qu’ils déposent sur le terminal de l'internaute. Voici, par exemple, l’un des (nombreux) cookies tels que déposés après identification (via le protocole HTTPS). Il contient nom, prénom et e-mail de l'internaute :

HTTP/1.1 200 OK

Content-Type: text/javascript; charset=utf-8

Date: Thu, 02 Jul 2015 20:35:07 GMT

Expires: now

Pragma: no-cache

Server: Apache

Set-Cookie: info_user_web=%7B%22jelec%22%3A%7B%22droit%22%3A0%7D%2C%22nom%22%3A%22LABARTHE%22%2C%22prenom%22%3A%22%22%Stephane%22%3A%22%22%2C%22email%22%3A%22slabarthe%40cnil.fr ; path=/; domain=.monsite.fr

Set-Cookie: info_user_web_track=%3Fage%3D%26prof%3D%26abo%3D0%26civ%3D%26cp%3D%26pays%3D%26pub%3D0%26quo%3D1%26web%3D%26pub_lm%3D0%26pub_lmfr%3D0; path=/; domain=.monsite.fr

Or, de nombreuses pages de « monsite.fr » ne sont pas accessibles en HTTPS. Ainsi, l’internaute, au cours de sa navigation, oscille entre des pages en HTTPS et des pages en HTTP.

Il en résulte que, sur les pages accessibles en HTTP, ce cookie, contenant un certain nombre de données personnelles, est transmis en clair.

Pour contrer ce phénomène, il existe plusieurs solutions. Il est possible d’utiliser l’attribut « secure » sur ce cookie. Ainsi, il sera transmis par le navigateur uniquement lors d’appels de pages utilisant un protocole sécurisé (RFC 6265).

Une autre solution, plus radicale, est de forcer l’utilisation du protocole HTTPS pour l’intégralité du site, via le HSTS.

4.2 Le HSTS − politique de chiffrement pour l’intégralité d’un domaine

Le protocole HTTP Strict Transport Security [HSTS] est un mécanisme de politique de sécurité proposé pour HTTP permettant à un serveur web d’indiquer au navigateur, s’il est compatible, qu’il doit communiquer avec lui en utilisant une connexion sécurisée.

Lorsque la politique HSTS est active pour un site web, le navigateur de l’utilisateur remplace automatiquement tous les liens non sécurisés par des liens sécurisés (http://www.mon-site.fr devient https://www.mon-site.fr). Ainsi, toutes les données transmises, y compris les dépôts et lectures de cookies, le sont sur un canal chiffré.

En cas d’impossibilité d’établir une connexion sécurisée, un message d’alerte est affiché à l’utilisateur.

Attention à l’utilisation de l’HSTS

N.B. : l’HSTS, mécanisme de sécurité simple, mais relativement puissant, doit être utilisé avec prudence. En cas de difficulté avec les certificats SSL/TLS, un navigateur ayant préalablement activé la politique HSTS se verra dans l’impossibilité d’accéder au site web si l’accès en HTTPS est inopérant.

4.3 L'attribut HTTPOnly

Les cookies sont fournis à chaque requête HTTP au serveur web correspondant. Par ailleurs, ils sont accessibles aux fonctions JavaScript qui s'exécutent dans la page. Cela peut représenter un danger et permettre par exemple à des « partenaires » ayant fourni ce type de code d'accéder à d'autres cookies que les leurs ou à un pirate de mener une attaque de type XSS pour « voler » des cookies.

Une bonne pratique, dès lors que le cookie stocke des données sensibles (cookie d'authentification, contenant des données personnelles, etc.), est d'utiliser l'attribut « HTTPOnly » qui indique que le cookie est uniquement accessible via HTTP(s).

* Les avis, opinions et positions exprimées dans le présent article n’engagent que leurs auteurs et en aucun cas l’institution à laquelle ils appartiennent 

Références

[LSO] Local Shared Objects (cookies flash) :

- https://fr.wikipedia.org/wiki/Objet_local_partag%C3%A9

- https://www.adobe.com/fr/special/products/flashplayer/articles/lso/

- https://www.adobe.com/fr/support/flashplayer/ts/documents/4c68e546.htm

[RFC6265] RFC 6265 (HTTP State Management Mechanism) : http://tools.ietf.org/html/rfc6265

 [HSTS] HSTS sur Wikipédia : https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[CookieViz] Dépôt CookieViz sur GitHub : https://github.com/LaboCNIL/CookieViz

[CookieManager +] https://addons.mozilla.org/fr/firefox/addon/cookies-manager-plus/

[LiveHTTPHeaders] https://addons.mozilla.org/fr/firefox/addon/live-http-headers/

[MISC-Analyse] Article MISC n°76 (nov./déc. 2014) : « Analyse d'une inscription en ligne : comment vos données fuitent sur Internet ».

[CNIL-CONSEILS] Cookies : conseils pour les maîtriser, rubrique sur le site Internet de la CNIL accessible à l'URL : http://www.cnil.fr/vos-droits/vos-traces/les-cookies/conseils-aux-internautes/

 



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

PostgreSQL au centre de votre SI avec PostgREST

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Dans un système d’information, il devient de plus en plus important d’avoir la possibilité d’échanger des données entre applications. Ce passage au stade de l’interopérabilité est généralement confié à des services web autorisant la mise en œuvre d’un couplage faible entre composants. C’est justement ce que permet de faire PostgREST pour les bases de données PostgreSQL.

La place de l’Intelligence Artificielle dans les entreprises

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

L’intelligence artificielle est en train de redéfinir le paysage professionnel. De l’automatisation des tâches répétitives à la cybersécurité, en passant par l’analyse des données, l’IA s’immisce dans tous les aspects de l’entreprise moderne. Toutefois, cette révolution technologique soulève des questions éthiques et sociétales, notamment sur l’avenir des emplois. Cet article se penche sur l’évolution de l’IA, ses applications variées, et les enjeux qu’elle engendre dans le monde du travail.

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 68 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous