Testing for cookies attributes (OTG-SESS-002)
This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.
OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here
This is a draft of a section of the new Testing Guide v3
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
Now that you have an understanding of how cookies are set, when they are set, what they are used for, why they are used, and their importance; lets take a look at what attributes can be set for a cookie and how to test if they are secure. The following is a list of the attributes that can be set for each cookie and what they mean. The next section will focus on how to test for each attribute.
- secure - This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests.
If the application can be accessed over HTTP and HTTPS then their is the potential that the cookie can be sent in cleartext.
- 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 its 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 to 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 to 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 applications 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 Topic X 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 it the browser believes it safe to pass via an unencrypted channel such as using HTTP.
Gray Box testing and example
Testing for Topic X vulnerabilities:
- Intercepting Proxy
- Browser Plug-in