Les Consultants Margo ont participé à Devoxx France 2018, la conférence pour les Développeurs Passionnés organisée du 18 au 20 avril 2018 à Paris. Découvrez ci-dessous un premier compte-rendu dédié à la conférence sur les cookies HTTP qui était animée le jeudi 19 avril par Hubert Sablonnière.
Lou Montulli, co-fondateur de Netscape et créateur du Text Web Browser Lynx, est un informaticien américain à l’origine de la balise Blink ainsi que de la première Live Web Cam d’Internet. Il est également connu pour être l’inventeur des fameux Cookies HTTP.
Image par Peter Adams Photography
Les Cookies, à ne pas confondre avec les sessions serveur, sont stockés sous forme de petits fichiers par le navigateur et contiennent des informations envoyées par le serveur.
Les Cookies peuvent donc être vus comme un protocole de communication entre le serveur et le navigateur Web, qui définit un format particulier pour l’échange de données entre ces deux parties.
L’illustration suivante permet de mieux visualiser le fonctionnement des Cookies :
Mais que contient un cookie ?
Un Cookie contient toutes les informations dont le site Web a besoin pour tracer et améliorer l’expérience utilisateur.
Comment cela se traduit-il techniquement ?
Comment un site Web reconnaît-il ses Cookies ?
Un site web peut écrire des Cookies via le navigateur, mais comment retrouve-t-il les Cookies qu’il a déjà produits ? Et surtout, comment empêche-t-il les autres sites d’accéder à ses Cookies ?
Les Cookies ne sont accessibles que via des règles bien particulières en rapport avec les URL.
Set-Cookie: name=Cookie; Domain=cookies.rocks Set-Cookie: name=Blue Cookie; Domain=blue.cookies.rocks Set-Cookie: name=Big Blue Cookie; Domain=big.blue.cookies.rocks
Chacun de ces Cookies ne sera valable et visible que pour les domaines qui correspondent hiérarchiquement.
Ainsi, dans cet exemple, “Big Blue Cookies” et “Blue Cookies” seront envoyés lors d’une requête à “blue.cookies.rocks” alors que “Cookie” ne sera pas envoyé.
Les Cookies des sous-domaines sont envoyés lors de la requête au domaine parent.
Qu’en est-il des Cookies avec un domaine en “.com” ?
Il est interdit de créer des Cookies avec un domaine en “.com”. Pour des raisons de sécurité évidentes, il existe toute une liste de domaines publics interdits :
Extrait
fr com.fr asso.fr nom.fr prd.fr presse.fr tm.fr // domaines sectoriels : http://www.afnic.fr/obtenir/chartes/nommage-fr/annexe-sectoriels aeroport.fr assedic.fr avocat.fr avoues.fr cci.fr chambagri.fr chirurgiens-dentistes.fr experts-comptables.fr geometre-expert.fr gouv.fr greta.fr huissier-justice.fr medecin.fr notaires.fr pharmacien.fr port.fr veterinaire.fr |
La liste complète est disponible ici : https://publicsuffix.org/
Les navigateurs se basent tous sur cette liste pour pouvoir interdire la création de Cookies sur un domaine public.
Les protocoles
Aujourd’hui, de plus en plus de sites web utilisent le protocope HTTPS. Ce protocole permet de chiffrer les requêtes entre un utilisateur et un site internet, ce qui renforce la sécurité, notamment contre les attaques du type Man In The Middle.
Il est donc possible de gérer les Cookies uniquement pour du HTTPS via le flag “Secure”.
Set-Cookie: name=value; Secure
Ainsi une requête envoyée au serveur via le protocole HTTP n’enverra pas les Cookies de type Secure.
Il est également possible de contraindre un navigateur à communiquer avec un serveur en HTTPS via le header HSTS.
Strict-Transport-Security: max-age=86400; includeSubDomains
Ainsi, s’il existe des liens dans la page qui ne sont pas sécurisés, le navigateur se chargera de remplacer ces liens par des liens sécurisés.
Same Origin Policy
La Same Origin Policy empêche un site internet d’interagir avec les Cookies d’un autre site.
Par exemple, imaginons un instant que voleurs.fr puisse interargir avec mabanque.fr. Ce serait terrible. Pour éviter cela, la Same Origin Policy impose aux sites Web à ne communiquer qu’avec eux-mêmes.
La Same Origin Policy a été mise en place en 1995, alors que les Cookies datent de 1994. Leur mode de fonctionnement diffère sur un petit détail qui a toute son importance : la Same Origin Policy se base sur le protocole, le domaine et le port correspondent. Les cookies eux, ne prennent en considération que le domaine.
Ainsi, si un site Web en HTTP partage le même domaine qu’un autre site Web en HTTPS, le premier peut donc modifier les Cookies du second. C’est cette technique qui est utilisée lors d’une attaque du type Man In The Middle.
Détournement de Cookies
Imaginons qu’un utilisateur visite mabanque.fr en HTTPS pour consulter ses comptes et que, en parallèle, il décide de se divertir avec videos-de-chats.fr en HTTP. Si videos-de-chats.fr effectue une requête en HTTP vers mabanque.fr, cette requête sera en mesure d’utiliser ou de modifier les Cookies de mabanque.fr, même ceux en HTTPS.
Bien-entendu, si le site Web mabanque.fr possède le HSTS, celui-ci protège ses utilisateurs contre ce genre d’attaque.
Renforcement des Cookies
Une nouvelle fonctionnalité a vu le jour, permettant de renforcer la sécurité autour des Cookies et de prévenir ce genre d’attaque.
Les Cookies avec préfixes __Secure- ou __Host-, obligent l’utilisation du flag Secure et forcent un changement de policy au niveau du navigateur.
La lecture et la modification ne sont accessibles que via le protocole HTTPS.
Pour le moment, seules les dernières versions de Chrome et Firefox supportent les Cookies préfixés.
Conclusion
Les Cookies sont souvent utilisés pour stocker des données utilisateurs ou même des informations liées à l’authentification de ce dernier.
Il faut être conscient des dangers et des risques encourus, les conséquences pouvant être terribles.
Il ne faut pas pour autant délaisser les Cookies, ils sont de précieux alliés, car il existe des moyens de sécuriser leur utilisation.
Sources: https://github.com/hsablonniere/talk-back-to-basics-cookies/blob/master/src/slide-deck.adoc
https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/