Qui aurait imaginé l’importance de ce petit fichier informatique, inventé quasiment en mode bidouille, et sur lequel repose aujourd’hui tant de fonctions y compris de sécurité ?

Recette de cookie

Utilisé au départ pour stocker des informations de type clé/valeur, le cookie s’accompagne d’informations optionnelles mais ayant un intérêt considérable selon l’utilisation faite de ce cookie.

• Domaine : c’est la portée du cookie, qui peut être sur un domaine, un sous-domaine. Ex : .mondomaine.com portera sur tous les sous-domaines correspondants (équivalent à *.mondomaine.com), alors que prive.mondomaine.com ne concernera que ce sous-domaine ; l’absence de . au début signifiera qu’on ne s’adresse qu’au domaine explicitement décrit ;
• Chemin : portée du cookie au niveau du chemin (= ce qui suit le nom de domaine dans l’URL), par exemple / ou /docs ;
• Expiration, ou Max-Age : durée de vie du cookie ;
• Secure : indique que le cookie ne sera envoyé qu’à travers https. par défaut, http et https sont permis ;
• HttpOnly : indique que le cookie ne sera transmis qu’en mode http. Ainsi le JavaScript est exclus, ce qui peut être gênant dans certaines circonstances mais ce qui a l’avantage d’empêcher le XSS en empêchant le JavaScript de lire le contenu du cookie ;
• SameSite : indique si le cookie peut être envoyé sur d’autres sites ou non ; par exemple, s’il est positionné à Strict, le cookie ne sera renvoyé que si la requête vient de l’URL courante. La valeur Lax autorise le transfert mais uniquement quand on quitte le site en cours (pas de cross-scripting autorisé).

Voir aussi https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Set-Cookie#Attributs.

Différentes saveurs : utilisation

Cookies traceurs

Je parlerai de ceux-ci dans un article séparé, avec les références de la CNIL sur le sujet.

Cookies d’authentification

Un usage très répandu des cookies est de servir à l’authentification d’un utilisateur : on stocke alors une identifiant de session dans un cookie dès que l’utilisateur est authentifié.

Ainsi, quand on revient sur un site sur lequel on est authentifié (ou tout du moins connu), les cookies (dont le cookie d’authentification) sont envoyés au serveur d’application, indiquant à quelle session rattacher les requêtes qui sont passées via le navigateur (chaque utilisateur ayant une session propre).

Tant que le cookie d’authentification est valide, tout utilisateur disposant de cet identifiant de session peut donc se connecter à la session de l’utilisateur : cet identifiant doit donc rester secret et non partagé.

Non prévisible

Cet identifiant de session doit donc être imprévisible ! S’il est facile de le deviner, un attaquant arrivera facilement à en forger un s’attachant à une session valide. Il pourra donc tout aussi facilement usurper l’utilisateur infortuné…

Etant en général généré côté serveur, l’utilisateur ne peut rien faire pour améliorer les choses. A contrario, l’algorithme utilisé par le serveur doit être robuste, et il convient d’éviter de réinventer la roue et d’utiliser des méthodes éprouvées de génération d’identifiant.

Non partagé

Ici, l’utilisateur peut avoir sa part de responsabilité : son navigateur peut avoir une faille sur la protection des cookies (il faut alors le mettre à jour dès parution du correctif), un attaquant peut lui avoir envoyé un lien douteux pour faire du XSS…

Pour éviter le XSS, le plus simple est de limiter l’accès aux cookies aux seules requêtes http(s) et interdire l’accès via JavaScript. On positionnera donc httpOnly pour les cookies à protéger (côté serveur).

Côté serveur encore : autant ne pas laisser les cookies importants se propager en clair : mention Secure obligatoire ! Sinon il pourrait transiter en clair via http…

Cycle de vie bien géré

Imaginons que vous ayez bien protégé votre cookie d’authentification. A la déconnexion de l’utilisateur, vous le supprimez du navigateur. C’est bien. Mais imaginons qu’un attaquant ait pu le lire, le transférer, et donc en connaître le contenu : il pourra se reconnecter sans problème si, en même temps, vous n’invalidez pas la session côté serveur ! Tant que la session sera active, disposer de l’identifiant de session suffira à se connecter et à usurper l’utilisateur…

Idem lors de la connexion : ne réutilisez pas l’identifiant de session pour réaliser la connexion ! Regénérez un identifiant !

Attaques sur les cookies

C’est en voulant vérifier une information sur une faille potentielle d’un site web bancaire que je me suis penché sur la question, et je me suis alors rendu compte que je savais finalement assez peu de choses sur les cookies, du point de vue technique.

L’attaque en question

Une banque ayant une forte activité en ligne a intégré dans son site web des mesures d’audience, confiées à des partenaires externes. Rien d’extraordinaire à part que, pour éviter les bloqueurs de publicité, le prestataire en question a eu le droit d’utiliser, par délégation, un sous-domaine de la banque en question.

Ainsi, si la banque avait pour domaine mabanque.com, le prestataire utilisait un sous-domaine du type cdn.mabanque.com, espérant ainsi échapper aux bloqueurs, grâce à un sous-domaine « légitime ».

Sauf que la banque en question a positionné le cookie d’authentification sur un domaine large, à savoir .mabanque.com. Et donc le cookie était accessible au tiers externe utilisant le sous-domaine cdn.mabanque.com, ce qui n’est pas bien.

Autres types d’attaque

XSS via Cookie

C’est une utilisation maligne d’un cookie : on met dans la valeur du cookie un script qui sera interprété en tant que tel s’il n’est pas correctement échappé. Pratique pour avoir de la persistance côté client…

Fixation de session

Cette attaque fait l’objet d’un articlé dédié.