Cookie Security and Session Hijacking in Web ApplicationsCookie security is a very important aspect of every website and goes hand in hand with HTTPS encryption and session management.
This article is part of a series of articles. Please use the links below to navigate between the articles.
- An Introduction to Hacking and Cyber Security - Complete Guide
- An Introduction and Brief History of Cryptography and Codebreaking
- Online Privacy and Why it Matters in Today's Hyper-Connected World
- What Are Supercookies? The Web's Latest Tracking Device
- How to Spot Scam and Phishing Emails And Avoid Being Scammed
- How Internet Security and SSL Works to Secure the Internet
- What is Man in the Middle Hacking and Transport Layer Protection
- What is Social Engineering And How Is It Used To Hack Systems
- Cookie Security and Session Hijacking in Web Applications
- What is Cross Site Scripting? (XSS) How is it Used to Attack Websites
- What is Internal Implementation Disclosure?
- What is Parameter Tampering and How to Protect Against It
- What is SQL injection - With Examples & Prevention
In this tutorial we will look at what cookie security is, why its important, the ways in which it can be abused and how we can make sure cookies are secure.
To start looking at cookie security, I will switch back 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. For each subsequent request to the site, I will send this cookie so the server knows who I am.
Now, this is where Cookie Inspector comes in. I will open a new Chrome Incognito window (which has no history, cookies or cache), and I will pretend to be the man in the middle. I will 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. 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. 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. 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 isn't much of a 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 secure. That is, it is only sent over a secure connection. Any request not sent over a secure connection will not have the cookie attached. The path can also restrict cookies; for example, if all the sensitive information is stored in the ~/my account/ 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.
However, The best practice to serve static resources, such as images and scripts that do not need cookies, is to load them from a separate cookieless domain.
In a nutshell, SSL allows us to authenticate who we are talking to - as long as a trusted authority signs the SSL certificate. 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 to ensure 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 whether a cookie is HttpOnly 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) 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 reducing these risks involves 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 a short cookie lifetime can be more secure; users may have to re-authenticate more frequently. Conversely, longer lifetimes are less secure as the authentication information is available longer but more convenient for the user as they don't have to revalidate all the time.
