Cookie Security and Session Hijacking in Web Applications

Cookie security is a very important aspect of every website and goes hand in hand with HTTPS encryption and session management.

In order to start looking at cookie security, I'm going to switch back over to the insecure login page and demonstrate what happens with cookies over an insecure connection and cookies over a secure connection. I've just logged into the login page, and the server has returned the response, including a Cookie. From the header information, you can see the cookie is called PHPSESSID. This cookie contains a long random string used to identify my session. Each subsequent request to the site will send this cookie so that the server knows who I am.

Now, this is where Cookie Inspector comes in. I'm going to open a new Chrome Incognito window (which has no history, cookies or cache) and I'm going to pretend to be the man in the middle. I'm going to copy that cookie information from the response header and add it to the cookie collection for the site in this new tab.

Now when I refresh the page - voila! I'm magically logged in and have full access to the site. Clearly sending authentication cookies in plain text like this is a very bad thing to do. All it takes is for someone to intercept the request or response information and copy that cookie value and they have total control over that account. It's not just the login process that sends this cookie, EVERY request to the server will send this cookie information - even requests to images, stylesheets, scripts and such will contain this sensitive information. Clearly, the window of risk is very large. It only takes one request to be intercepted for a hacker to gain control. This type of attack is called a session hijack attack.

Securing Cookies

This is where SSL comes in. When you load a page over SSL, the cookies are encrypted and only the destination server and your browser can decrypt and view them. You must, however, ensure that every request is sent via SSL - all web pages and resources.

Now, there doesn't seem to be much need to request images over an SSL connection, they are not sensitive information, so you can set an option when creating the cookie to make it a secure cookie. That is it is only sent over a secure connection. Any request that is not sent over a secure connection will not have the cookie attached. Cookies can also be restricted by path, so for example, if all the sensitive information is stored in the ~/myaccount/ path only requests to that path will use the cookie. Everywhere else on the site won't send the cookie. You should set a reasonable cookie expiration as well. Having the cookie expire when the browser is closed is good for security, especially with laptops and mobile devices.

The best practice however to serve static resources, such as images and scripts which do not need cookies, is to load them from a separate cookieless domain.

In a nutshell, SSL gives us the ability to authenticate who we are talking to - as long as the SSL certificate is signed by a trusted authority. It provides integrity so we can be confident that the content of the request/response has not been manipulated in some way. Finally, it gives us confidentiality in that we can be sure that the content hasn't been eavesdropped by a man in the middle.

Using HttpOnly when generating a cookie helps mitigate the risk of the client side script accessing the protected cookie. This means that client-side scripts such as JavaScript can potentially access authentication details from the AuthCookie and send them to a remote user who can then hijack the session. You can see if a cookie is HttpOnly or not by looking in the Chrome developer tools. In the resources tab, you can expand the cookies tree and view the cookies set by the site. HttpOnly cookies have a tick in the HTTP column.

Using secure cookies helps mitigate the risk of sending auth cookies (or any cookie) being sent when an unsecured resource is requested (for example an image served with HTTP on a secure HTTPS page). Again, secure cookies can be identified in Chrome developer tools in the Secure column.

Further methods for reducing these risks involve limiting the cookie path, for example, the cookie can be set to valid for URLs in the /admin/ directory anything outside of this won't send the cookie.

Using cookie expiration means that the lifetime of the cookie can be changed. There is a balance here since short cookie lifetime can be more secure, for the user they may have to re-authenticate more frequently. Conversely, longer lifetimes are less secure as the authentication information is available for a longer period but more convenient for the user as they don't have to revalidate all the time.