Testing for cookies attributes (OWASP-SM-002)

Revision as of 11:43, 22 July 2008 by Rick.mitchell (Talk | contribs)

Jump to: navigation, search

OWASP Testing Guide v3 Table of Contents




Brief Summary

Cookies are often a key attack vector for malicious users (typically targeting other users) and as such the application should always take due diligence to protect these cookies. In this section we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.

Description of the Issue

The importance and secure use of Cookies cannot be understated, especially within dynamic web applications which need to maintain state across a stateless protocol such as HTTP. To understand the importance of cookies it is imperative to understand what they are primarily used for. These primary functions usually consist of being used as a session authorization/authentication token or as a temporary data container. Thus if an attacker were by some means able to acquire a session token such as by cross site scripting (XSS) or sniffing an unencrypted session then he/she could use this cookie to hijack a valid session. Additionally, cookies are set to maintain state across multiple requests. Since HTTP is stateless the server cannot determine if a request it receives is part of a current session or the start of a new session without some type of identifier. This identifier is very commonly a cookie although not always. As you can imagine there are many different types of applications that need to keep track of session state across multiple requests. The primary one that comes to mind would be an online store. As a user adds multiple items to a shopping cart this data needs to be retained in subsequent requests to the application. Cookies are very commonly used for this task and are set by the application using the Set-Cookie directive in the application's HTTP response, and is usually in a name=value format (if cookies are enabled and if they are supported, which is the case for all modern web browsers). Once an application has told the browser to use a particular cookie the browser will send this cookie in each subsequent request. A cookie can contain data such as items from an online shopping cart, the price of these items, the quantity of these items, personal information, user IDs, etc. Due to the sensitive nature of information in cookies they are typically encoded or encrypted in an attempt to protect the information they contain. Many times multiple cookies will be set (separated by a semicolon) upon subsequent requests especially in the case of an online store as you add multiple items to your shopping cart. Additionally you will typically have a cookie for authentication (session token as indicated above) once you login and multiple other cookies used to identify the items you wish to purchase and their auxiliary information (i.e. price, quantity, etc) in the online store type of application.



If the application can be accessed over both HTTP and HTTPS then there is the potential that the cookie can be sent in clear text.

  • domain - This attribute is used to compare against the domain of the server in which the URL is being requested. If the domain matches or if it is a sub-domain then the path attribute will be checked next.

Note that only hosts within the specified domain can set a cookie for that domain. Also the domain attribute can not be a top level domain (such as .gov or .com) to prevent against servers being able to set arbitrary cookies for another domain. If domain attribute is not set then the default value of domain is set to the hostname of the server which generated the cookie. 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 subdomains (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, its subdomains such as hacker.app.mydomain.com, and even bank.mydomain.com. If there was a vulnerable server on a subdomain such as (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 can be specified for which the cookie is valid. 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 attack 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.

Black Box testing and example

Testing for cookie attribute vulnerabilities:

Using an intercepting proxy or browser plugin 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 believes it safe to pass via an unencrypted channel such as using HTTP.
  • 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 - Verify that if this attribute is set to a time in the future that it does not contain any sensitive information. For example if a cookie is set to "; expires=Fri, 13-Jun-2010 13:45:29 GMT" and it is currently June 10th 2008 then you want to 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.



  • RFC 2965 - HTTP State Management Mechanism -


  • RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -



Intercepting Proxy:

  • OWASP: Webscarab -


  • Dafydd Stuttard: Burp proxy -


  • MileSCAN: Paros Proxy -


Browser Plug-in:

  • "TamperIE" for Internet Explorer -


  • Adam Judson: "Tamper Data" for Firefox -