This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

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

From OWASP
Revision as of 23:53, 20 November 2014 by Jcpraud (talk | contribs) (Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == Les cookies sont un vecteur d'attaque clef pour les utilisateurs malicieux (ciblant typiquement les autres utilisateurs) et...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
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

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é.


Seulement 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.


For example, if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its sub-domains (such as hacker.app.mydomain.com), but not to otherapp.mydomain.com. If a developer wanted to loosen this restriction, then he could set the domain attribute to mydomain.com. In this case the cookie would be sent to all requests for app.mydomain.com and its sub domains, such as hacker.app.mydomain.com, and even bank.mydomain.com. If there was a vulnerable server on a sub domain (for example, otherapp.mydomain.com) and the domain attribute has been set too loosely (for example, mydomain.com), then the vulnerable server could be used to harvest cookies (such as session tokens).


  • path - In addition to the domain, the URL path that the cookie is valid for can be specified. If the domain and path match, then the cookie will be sent in the request. Just as with the domain attribute, if the path attribute is set too loosely, then it could leave the application vulnerable to attacks by other applications on the same server. For example, if the path attribute was set to the web server root "/", then the application cookies will be sent to every application within the same domain.
  • expires - This attribute is used to set persistent cookies, since the cookie does not expire until the set date is exceeded. This persistent cookie will be used by this browser session and subsequent sessions until the cookie expires. Once the expiration date has exceeded, the browser will delete the cookie. Alternatively, if this attribute is not set, then the cookie is only valid in the current browser session and the cookie will be deleted when the session ends.

How to Test

Black Box Testing

Testing for cookie attribute vulnerabilities:

By using an intercepting proxy or traffic intercepting browser plug-in, trap all responses where a cookie is set by the application (using the Set-cookie directive) and inspect the cookie for the following:

  • Secure Attribute - Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted tunnel. For example, after logging into an application and a session token is set using a cookie, then verify it is tagged using the ";secure" flag. If it is not, then the browser would agree to pass it via an unencrypted channel such as using HTTP, and this could lead to an attacker leading users into submitting their cookie over an insecure channel.
  • HttpOnly Attribute - This attribute should always be set even though not every browser supports it. This attribute aids in securing the cookie from being accessed by a client side script, it does not eliminate cross site scripting risks but does eliminate some exploitation vectors. Check to see if the ";HttpOnly" tag has been set.
  • Domain Attribute - Verify that the domain has not been set too loosely. As noted above, it should only be set for the server that needs to receive the cookie. For example if the application resides on server app.mysite.com, then it should be set to "; domain=app.mysite.com" and NOT "; domain=.mysite.com" as this would allow other potentially vulnerable servers to receive the cookie.
  • Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set too loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example, if the application resides at /myapp/, then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used, the browser will send the cookie to any path that matches "myapp" such as "myapp-exploited".
  • Expires Attribute - If this attribute is set to a time in the future verify that the cookie does not contain any sensitive information. For example, if a cookie is set to "; expires=Sun, 31-Jul-2016 13:45:29 GMT" and it is currently July 31st 2014, then the tester should inspect the cookie. If the cookie is a session token that is stored on the user's hard drive then an attacker or local user (such as an admin) who has access to this cookie can access the application by resubmitting this token until the expiration date passes.


Tools

Intercepting Proxy:

Browser Plug-in:

  • "TamperIE" for Internet Explorer -

http://www.bayden.com/TamperIE/

  • Adam Judson: "Tamper Data" for Firefox -

https://addons.mozilla.org/en-US/firefox/addon/966


References

Whitepapers