Why you should use secure cookies

Cookies are used for authentication within web applications. If the cookies are not correctly set sessions can be hijacked easily.

Because a lot of web applications have cookies set with the domain (Domain=.domain.com or Domain=domain.com) option, all subdomains below this domain will serve the cookies as well. Not everyone is aware of the fact that the second example will work also for subdomains, if you need the cookie only to work on the actual domain, you should not set a domain.

When the cookie will be set for subdomains and the secure attribute is not set, the application can be vulnerable to session hijacking by dns cache poisoning. Because the browser will deliver cookies set on the secure (https) webapplication also to (http) subdomains, malicious applications can serve on subdomains (a98347tnnien.domain.com) and retrieve the authentication tickets. You can prevent this behaviour by using the secure option of the cookie specification. By setting this option, cookies will be delivered only on https connections. The attacker needs to serve a certificate of the domain also. Certificate authorities should prevent this.

The HttpOnly option will prevent access from javascript to the cookie. For example in vulnerable XSS applications, this disables the option to read the cookie from javascript.

So the very important rules of setting cookies:

  • set the HttpOnly option if you don't need the cookie in javascript
  • set the Domain option if subdomains need to read the cookie as well
  • set the Secure option if you are using secure connections (and you should)
Set-Cookie: LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly  

References

http://en.wikipedia.org/wiki/HTTPcookie#Publishingfalsesub-domain.E2.80.93DNScache_poisoning