Sécurisez vos cookies (instructions Secure et HttpOnly)

Les cookies sont omniprésents sur le web et permettent aux éditeurs de stocker un certain nombre d’informations directement sur le navigateur de l’internaute. Notamment utilisés pour identifier la session de l’utilisateur et permettre au serveur de reconnaître celui-ci tout au long de sa navigation, les cookies contiennent souvent des informations personnelles et/ou sensibles. Il convient donc de les protéger en conséquence.

Comment sécuriser les cookies

L’en-tête HTTP Set-Cookie

Pour rappel, un cookie est généralement créé sur le navigateur à la demande du serveur web pour stocker un état, qui sera ensuite retransmis sur les prochaines requêtes. Le serveur web utilise pour cela l’en-tête Set-Cookie dans une réponse HTTP.

Voici la syntaxe de cet en-tête :

Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]

Le cookie est identifié par un nom auquel on associe une valeur. Il peut disposer d’une durée de validité et/ou d’une date d’expiration. On notera que si les 2 instructions sont présentes, c’est la durée de validité (max-age) qui prendra le dessus. Enfin, il est possible pour le serveur de définir un chemin et un domaine pour lequel le cookie devra être utilisé. Un cookie n’est par défaut envoyé que sur le domaine responsable de l’avoir placé. Les instructions domain et path permettent éventuellement de restreindre sa portée, ou inversement de l’étendre, par exemple en autorisant son utilisation sur tous les sous-domaines.

Une première bonne pratique pour la sécurisation de vos cookies consiste justement à bien en maîtriser leurs portées respectives.

Les deux dernières instructions secure et HttpOnly, portent spécifiquement sur la sécurité. On notera qu’elles n’acceptent pas de valeurs, c’est leur présence ou non qui caractérise le comportement du navigateur vis-à-vis du cookie.

Interdire l’utilisation du cookie côté client avec l’instruction HttpOnly

Un cookie peut-être positionné et utilisé par un serveur web, mais aussi directement sur le navigateur en Javascript.

Dans le cas d’une faille XSS, un attaquant pourrait parvenir à injecter du Javascript, et donc potentiellement accéder aux cookies, qui rappelons-le, contiennent souvent des informations sensibles. Evidemment, il est avant tout préférable d’éviter les failles XSS. Ensuite, leur exploitation peut être empêchée par la définition d’une Content Security Policy.
L’utilisation de l’instruction “HttpOnly” empêche d’accéder aux cookies en Javascript : si malgré les protections précitées, un attaquant venait à injecter du Javascript, les cookies ne seront pas accessibles, ce qui limitera la portée de l’attaque.

Interdire l’utilisation du cookie sans HTTPs avec le flag Secure

Nous le répétons régulièrement sur ce blog, HTTPs est nécessaire pour votre site web. Si vous avez adopté ce protocole sécurisé, et que vous avez suivi les conseils précédents, vous vous dites peut-être que le cookie transite sur une communication sécurisée, qu’il n’est pas accessible en Javascript et donc non vulnérable à une attaque XSS.
Malheureusement, il reste un problème notable.

Et si votre internaute accède à votre site en HTTP, tout simplement en saisissant l’adresse directement sans préciser https:// ? Cela peut aussi être le cas si votre page comporte des contenus mixtes (ou mixed content).

Certes, la mise en place d’un en-tête HSTS (HTTP Strict Transport Security), qui permet de forcer l’utilisation du HTTPS pour toute visite ultérieure peut fortement limiter le premier cas. Mais ce n’est pas supporté par tous les navigateurs, et il reste toujours le cas de la première visite. La Content Security Policy peut mitiger le deuxième cas, en évitant tout risque de mixed content pour les navigateurs qui la supportent.
Seul l’attribut secure vous permettra d’empêcher qu’un Cookie ne soit jamais communiqué en HTTP simple.

L’intérêt de cette instruction est d’ailleurs clairement évoqué dans la RFC HTTP State Management Mechanism :

Servers that require a higher level of security SHOULD use the Cookie and Set-Cookie headers only over a secure channel. When using cookies over a secure channel, servers SHOULD set the Secure attribute (see Section 4.1.2.5) for every cookie. If a server does not set the Secure attribute, the protection provided by the secure channel will be largely moot.

Évidemment, gardez à l’esprit qu’un cookie utilisant l’instruction Secure ne sera pas du tout envoyé sur la version HTTP simple de votre site. Attention par exemple si votre site fait encore cohabiter des espaces en HTTPs et d’autres en HTTP simple.

En conclusion, n’oubliez pas que notre outil d’analyse de pages web vous permettra en quelques instants de vous assurer que vos cookies sont sécurisés, en vérifiant la bonne utilisation de HttpOnly et de Secure !

Optimisation Cookie secure Dareboost