Détecter et analyser les cookies et autres traceurs

Magazine
Marque
MISC
Numéro
81
|
Mois de parution
septembre 2015
|
Domaines


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/


Sur le même sujet

Introduction au dossier : Ransomwares : état de la menace

Magazine
Marque
MISC
Numéro
107
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Il ne se passe plus un mois sans qu’un ransomware ne touche une entreprise ou administration publique et que cette dernière se retrouve dans une situation délicate, au point que cela atterrisse invariablement dans les colonnes de nos quotidiens (oui bon, dans les bandeaux des chaînes d’information continue). On pourrait simplement dire que l’histoire se répète, qu’il s’agit d’un énième malware qui touche des infrastructures qui ne sont pas à jour, mal configurées, et que tout cela était inéluctable.

Utilisation de services en ligne légitimes par les malwares

Magazine
Marque
MISC
Numéro
107
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Les fraudes sur Internet, qu’elles suivent une motivation financière ou autre, nécessitent généralement de l’ingénierie sociale, ou l’utilisation de malwares. Ces derniers sont plus ou moins furtifs au niveau de leur comportement sur le poste de travail infecté, mais aussi lors de leurs communications sur le réseau avec leur contrôleur, ou serveur de « command and control » (C2). Voulant rendre leur trafic moins détectable, certains cybercriminels ont misé sur l’utilisation de plateformes et services légitimes en ligne. Bien que cette méthode ne soit pas nouvelle en soi, elle tend à être de plus en plus utilisée depuis quelques années.

Programmation UEFI

Magazine
Marque
MISC
Numéro
107
|
Mois de parution
janvier 2020
|
Domaines
Résumé

La deuxième étape de la compréhension du système UEFI va s’articuler autour de l’implémentation en C avec l’optique de fabriquer sa propre brique UEFI. Le développement va permettre d’illustrer le processus de la chaîne de boot avec pour objectif de mieux appréhender les différentes problématiques de sécurité.

Maîtriser la sécurité de son accès Internet avec OpenWRT

Magazine
Marque
Linux Pratique
Numéro
117
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Nous allons voir dans cet article comment installer le système GNU/Linux embarqué de type OpenWRT. OpenWRT est un système GNU/Linux pour les matériels embarqués et pour les matériels de types routeurs et box. Il constitue donc la part essentielle pour se libérer des GAFA. C’est un système léger, rapide et performant pour administrer et contrôler son accès Internet. Ce système est optimisé pour la gestion des ressources et supporte de nombreux routeurs.

Par le même auteur

Détecter et analyser les cookies et autres traceurs

Magazine
Marque
MISC
Numéro
81
|
Mois de parution
septembre 2015
|
Domaines
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.

Analyse d'une inscription en ligne : comment vos données fuitent sur Internet…

Magazine
Marque
MISC
Numéro
76
|
Mois de parution
novembre 2014
|
Domaines
Résumé

Lorsqu’un internaute visite un site web ou s’y inscrit, il laisse certaines de ses données personnelles au site. Mais des acteurs tiers peuvent aussi en être destinataires… Peu visibles de l’internaute, ils agissent parfois à l’insu du site web lui-même. Ce sont d’abord des acteurs situés au niveau applicatif, dont le code source s'exécute directement dans la page web (régies publicitaires, services de mesure d’audience, plateformes RTB). Ce sont aussi les CDN, qui se positionnent comme des intermédiaires au niveau réseau. Nous vous proposons l'analyse de deux méthodes utilisées pour détecter ces fuites de données. Les exemples présentés dans cet article sont fictifs, mais fondés sur des situations réelles rencontrées lors de contrôles de la CNIL.