Four attributes to secure cookies

These days, not a single penetration test report or vulnerability scan report goes past my desk without a mention of a cookie vulnerability. In fact, it’s becoming a bit boring, so I thought I’d write about it here, so that future web applications are more ‘secure by design’.

For the uninitiated, “cookies” are files that written to computers to record important information about the web applications you are using. They are often used to store session token data, or as a temporary data repository, such as the contents of your shopping cart. Because cookies are used by applications like on-line banks, they are good fodder for hackers and the criminally inclined.

This blog is about securing cookies.

Cookies are a basic requirement of any web application because the HTTP protocol was not designed to support sessions.

If you consider the use of these four attributes when creating cookies, you may be able to avoid filling my desk up with your cookie problems.

Secure attribute – whenever a cookie contains sensitive information or is a session token, then it should be passed using an encrypted tunnel. Setting the secure attribute on a cookie is one way to ensure this.

HTTPOnly attribute – This attribute secures the cookie from being accessed by client side script, such as JavaScript, which may protect against the very common Cross-Site Scripting attacks.

Domain attribute – The domain attribute should be set for the specific application such as “; domain=app.mydomain.com” and NOT “; domain=.mydomain.com” as this would allow other potentially vulnerable servers to receive the cookie.

Path attribute – The path attribute should also be set as tight as possible. Even if the Domain attribute is set, a loose path attribute may create vulnerability to less secure applications on the same server. So if the application resides at /myapp/ then set the cookie path to “; path=/myapp/” and NOT “; path=/” or “; path=/myapp”. The trailing slash must be used after myapp, else the cookie can be sent to any path that matches “myapp” such as “myapp-hacked”.

For more information on developing secure web applications see www.owasp.org

Happy developing!