4.7.2 Tester les attributs des cookies (OTG-SESS-002)

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

1 Sommaire
2 Comment tester
- 2.1 Test en boite noire
3 Outils
4 References

Sommaire

Les cookies sont un vecteur d'attaque clef pour les utilisateurs malicieux (ciblant typiquement les autres utilisateurs) et les applications devraient toujours prendre les précautions nécessaires pour protéger les cookies. Cette section montre comment une application peut prendre les précautions nécessaires pour créer des cookies, et comment tester que ces attributs sont correctement configurés.

L'importance de l'utilisation sécurisée des cookies ne peut pas être sous-estimée, surtout dans le cas d'applications web dynamiques, qui nécessitent de maintenir un état par dessus un protocole sans état comme HTTP. Pour comprendre l'importance des cookies, il est impératif de comprendre pourquoi ils sont utilisés principalement. Les plus souvent, ils servent principalement de jeton d'autorisation et d'authentification de session ou de stockage temporaire de données. Ainsi, si un attaquant peut récupérer un jeton de session (par exemple, en exploitant une faille de cross site scripting ou en espionnant une session non chiffrée), il peut alors utiliser ce cookie pour s'approprier une session valide.

En outre, les cookies servent à maintenir un état entre plusieurs requêtes. Comme HTTP est sans état, s'il ne dispose pas d'un identifiant, le serveur ne peut pas déterminer si une requête fait partie d'une session existante ou est le départ d'une nouvelle session. Cet identifiant est le plus souvent un cookie, bien que d'autres méthodes soient possibles. Beaucoup de types d'applications nécessitent de conserver un état de session sur plusieurs requêtes. La principale qui vient à l'esprit est la boutique en ligne. Lorsqu'un utilisateur ajoute différents produits dans son panier, ces données doivent être conservées lors des requêtes suivantes. Les cookies sont très souvent utilisés pour cette tâche et sont créés par l'application au moyen de la directive Set-cookie dans la réponse HTTP de l'application, et contiennent souvent des paires nom=valeur (si les cookeis sont activés et s'ils sont supportés, ce qui le cas de tous les navigateurs modernes). Une fois qu'une application a ordonné au navigateur d'utiliser un cookie particulier, le navigateur va envoyer ce cookie lors de chacune de requêtes suivantes. Un cookie contient des données telles qu'un panier en ligne, le prix des produits, la quantité de chaque produit, des informations personnelles, des identifiants d'utilisateur, etc.

A cause des informations sensibles qu'ils contiennent, les cookies sont le plus souvent codés ou chiffrés. Souvent plusieurs cookies seront créés (séparés par des points-virgules) par plusieurs requêtes. Par exemple, dans le cas d'une boutique en ligne, un nouveau cookie sera créé pour chaque produit ajouté par l'utilisateur dans son panier. En outre, il y aura généralement un cookie d'authentification (jeton de session, comme indiqué plus haut) lorsque l'utilisateur se connecte sur son compte, ainsi que de multiples cookies pour chaque produits sélectionné, sa quantité, son prix, et autres information auxiliaires.

Une fois que le testeur a compris comment les cookies sont créés, quand ils sont créés, à quoi ils servent, pourquoi ils sont utilisés, et leur importance, il doit regarder quels attributs leur sont affectés et comment tester qu'ils sont sécurisés. Ci-dessous, une liste des attributs qui peuvent être affectés à chaque cookie, et leur signification. La section suivante sera consacrée à la manière de tester chaque attribut.

secure - Cet attribut dit au navigateur de n'envoyer ce cookie que vers un canal sécurisé comme HTTPS. Cela aidera à empêcher le cookie d'être transmis dans une requête non chiffrée. Si l'application est accessible en HTTP comme en HTTPS, il y a un risque que le cookie soit quand même transmis en clair.

HttpOnly - Cet attribut est utilisé pour aider à empêcher des attaques de type cross-site scripting, puisqu'il interdit au cookie d'être lu via un sript client comme JavaScript. Attention, tous les navigateurs ne supportent pas cette fonctionnalité.

domain - Cet attribut est utilisé pour être comparé au domaine du serveur sur lequel on requête l'URL. Si le domaine correspond, ou est un sous-domaine, alors l'attribut path sera ensuite vérifié.

Seuls les serveurs appartenant au domaine spécifié peuvent créer un cookie pour ce domaine. L'attribut domain ne peut pas être un top level domain (tel que .gov ou .com) afin d'empêcher des serveurs de créer des cookies harbitraires pour d'autres domaines. Si l'attribut domaine n'est pas spécifié, alors le nom d'hôte du serveur qui a généré le cookie est utilisé comme valeur par défaut pour le domaine.

Par exemple, si un cookie est créé par une application app.ondomaine.com sans attribut de domaine, ce cookie sera renvoyé lors de toutes les requêtes suivantes pour app.mondomaine.com et ses sous-domaines (comme pirate.app.mondomaine.com), mais pas à autreapp.mondomaine.com. Si un développeur veut assouplir cette restriction, il peut donner comme valeur à l'attribut de domaine mondomaine.com. Dans ce cas le cookie sera envoyé avec toutes les requêtes pour app.mondomaine.com et ses sous-domaines, comme pirate.mondomaine.com, et même à banque.mondomaine.com. S'il y a une vulnérabilité sur une serveur du sous-domaine (par exemple, autreapp.mondomaine.com) et que l'attribut de domaine a une valeur trop laxiste (par exemple mondomaine.com), alors cette vulnérabilité pourra être utilisée pour récupérer des cookies (comme les jetons de session).

path - En plus du domaine, on peut spécifier le chemin de l'URL pour lequel le cookie est valide. Si le domaine et le chemin correspondent, alors le cookie sera envoyé dans la requête. Comme pour l'attribut de domaine, si le chemin est trop laxiste, alors l'application pourra être vulnérable à des attaques par d'autres application sur le même serveur. Par exemple, si l'attribut de chemin est la racine du serveur web "/", alors les cookies de l'application seront envoyés à toutes les application du même domaine.

expire - Cet attribut concerne les cookies persistents, puisque ces cookies sont valides jusqu'à ce que leur date de validité soit dépassée. Les cookeis persistents sont utilisés par la session actuelle du navigateur et par les suivantes, jusqu'à date d'expiration. Une fois que la date d'expiration est dépassée, le navigateur supprime le cookie. Si cet attribut n'est pas précisé, le cookie ne sera valable que pendant la session actuelle du navigateur, et il sera supprimé à la fin de la session.

Comment tester

Test en boite noire

Tester les vulnérabilités des attributs de cookie :

En utilisant un proxy intercepteur de trafic, ou un plugin de navigateurs interceptant le trafic, capturez toutes les réponses créant un cookie (directive Set-cookie) et inspectez le cookie :

Secure - Quand un cookie contient des informations sensibles ou un jeton de session, il doit être envoyé par un canal chiffré. Par exemple, après authentification sur une application et création d'un jeton de session, vérifiez que le cookie est marqué avec l'option ";secure". S'il ne l'est pas, alors le navigateur permettra de l'envoyer via un canal non-chiffré comme HTTP, ce qui permettrait à un attaquant d'inciter les utilisateurs à envoyer leurs cookies sur un canal non sécurisé.

HttpOnly - Cet attribut devrait toujours être utilisé, même si tous les navigateurs ne le supportent pas. Il aide à empêcher que le cookie soit lu par un script client. Il n'élimine pas les risques de cross site scripting, mais en supprime certains veteurs d'exploitation. Vérifiez si l'attribut ";HttpOnly" a été activé.

Domain - Vérifiez que le domaine n'est pas trop souple. Comme indiqué précédemment, il ne devrait être positionné que pour le serveur qui a besoin de recevoir le cookie. Par exemple, si l'application est hébergée sur le serveur app.monsite.com, alors le domaine doit être "; domain=app.monsite.com" et PAS "; domain=.monsite.com" car cela permettrait à d'autres serveur potentiellement vulnérables de recevoir le cookie.

Path - Vérifiez que l'attribut path, comme l'attribut domain, n'est pas trop souple. Même si l'attribut domain est le plus strict possible, si le chemin est le répertoire racine "/", alors le cookie peut être vulnérable à d'autres application moins sécurisée sur le même serveur. Par exemple, si l'application est dans /monapp/, vérifiez que le chemin du cookie est "; path=/monapp/" et PAS "; path=/" ou "; path=/monapp". Notez que le "/" de fin doit être utilisé après monapp. S'il ne l'est pas, le navigateur enverra le cookie vers toute application qui correspondra à "monapp", tel que "monapp-exploited".

Expires - Si cet attribut est configuré sur une date dans le future, vérifiez que le cookie ne contient pas d'informations sensibles. Par exemple si un cookie est configuré "; expires=Sun, 31-Jul-2016 13:45:29 GMT" et que la date actuelle est le 31 juillet 2014, alors le testeur doit inspecter le cookie. Si le cookie est un jeton de session stocké sur le disque dur de l'utilisateur, alors un attaquant ou un utilisateur local (comme un administrateur système) qui a accès à ce cookie peut accéder à l'application en renvoyant ce jeton jusqu'à ce que la date d'expiration soit passée.