21 juin 2018
source
Hubert vient tous parler d’un sujet quasi-neuf : les cookies. Et évidement, comme chez les autres showmen de l’informatique, la forme compte autant que le fond.
Revenons en 1994. A cette époque, Lou Montuli travaille chez Netscape. Et le navigateur typique est Lynx (et pas links, sa version avec Javascript et autres). On y invente (un peu à cause de lui) la balise <blink>. Et il y invente également les gifs animés. Et enfin, il y invente les cookies, dont l’objectif était déja de maintenir une session côté client.
C’est un paquet d’information envoyé par le serveur (via l’entête http Set-Cookie). Le navigateur les stocke localement dans un cookie jar (une boîte à cookie). Et lorsqu’il refait une requête au même serveur, il renvoie les cookies que ce serveur a déja positionné (via l’entête cookie).
Par défaut, le cookie expire quand le navigateur est fermé. Sauf évidement quand le serveur envoie l’entête Expiration-Date ou Max-Age qui définit une date de suppression.
La méthode typique est d’envoyer une Expiration-Date dans le passé, ou un Max-Age de 0.
Domain=Avec cette attribut, le cookie est accessible sur tous les domaines dont le nom se termine par ce domaine. Par contre, on ne peut pas positionner un cookie sur un TLD (top level domain). Ces domaines sont tous listés sur http://publicsuffix.org.
On ne peut pas non plus définir comme domaine localhost.
Path
Si cet attribut est positionné, le cookie est positionné lorsque le path commence par le préfixe défini suivi par un /.
Secure
Lorsqu’il est positionné, le cookie n’est envoyé que pour les pages servies en https. ATTENTION ! cet attribut peut être positionné par une page non sécurisée (ce qui pourrait ouvrir la porte à toute une série de mauvaises requêtes).
L’entête HTTP Strict-Transport-Security garantit que toutes les requêtes suivantes seront effectuées en HTTPS, comme une redirection (mais sans aller-retour de la requête auprès du serveur.)
__
Deux préfixes de ce type existe : _ sur un nom de cookie et Host. chacun d’entre eux limite et le nombre de cas dans lesquels le cookie est servi.
Deux requêtes sur des ports différents serviront les mêmes ensembles de cookies. Heureusement, les navigateurs implémentent le same origin policy (qui identifie un serveur pour le local-storage, les requêtes Ajax). Malheureusement, celui-ci n’est pas utilisé pour les cookies.
Evidement ! Et du coup, c’est ce qui ouvre la porte aux attaques cross-server (CSRF & co). A noter qu’on peut les inclure dans des images. Mais comme le dit Hubert, entre gens de bonne compagnie, on ne fait pas de requêtes GET pour mettre à jour un site web.
SameSiteAvec cet attribut, les cookies ne sont envoyés que lorsqu’il sont servis par une page issue du même site.
Le navigateur, mais aussi l’API Javascript document.cookie … qui est sacrément étrange.
Le sujet est vaste.
HttpOnlyQuand il est positionné, les Javascript dans la page ne peuvent pas accéder au cookie.
Le tour d’horizon était chouette. Et évidement, Hubert est un sacré showman qui maîtrise (presque) tous ses effets.