Securing Cookies in Web Applications

It is very common practice for web applications to transmit sensitive user information such as session token through cookies. Each time the user's web browser returns a session cookie, there is some concern that intercepting a user's session cookie can compromise a user’s session information. If a web application contains such information, it's important to prevent access to the cookie information. You can prevent interception of session cookies by encrypting the communication link between your web server and the user's browser. But is it all it takes to secure a session cookie? I believe it may partially prevent accessing the cookie information through interception, but it may not prevent gaining access to cookie information through other means. Here I'll explain the attack scenario's that may still be used to gain unauthorised access to cookie information even if an SSL connection is used.

Scenario 1:

A user is browsing to an authenticated portion of a Banking web site (https://www.MyBank.com). The web site uses secure HTTPS connection to protect sensitive user information including the session cookie. The user is accessing his web mail account in another browser tab at the same time. He has just received a phishing email from an attacker that appears to have come from his Banking web site. The email requires the user to verify his account security by clicking on a link within the email (http://www.MyBank.com). Note that the link in the email uses a clear text HTTP connection instead of a secure HTTPS connection. Once the user clicks on the link, it transmits the session cookie along with everything else in the clear text. The session cookie for the MyBank web site is automatically sent in this case because the user is already authenticated to the web site at the time of clicking on the link in the email. This enables an attacker to capture session token by sniffing the network traffic and enabling him to compromise a victim's account by replaying this session token to the target web site while the session is still active.

The web application owners may think that they are using an SSL connection to protect sniffing of session cookie and thus it may not be possible for an attacker to capture the session token within the cookie. The above scenario shows that an attacker can capture session token by launching an attack even if the web server does not support HTTP connection at all. In this case, web server sends an error back to the end user, but the session token has already been compromised while the request was send by the browser to the web server.

Mitigation: This type of cookie hijacking attack could be prevented by using a 'Secure' flag while setting a new cookie. Any cookie that contains session token or any other sensitive user information should be marked as Secure. If a cookie is marked Secure, it will only be transmitted if the communications channel with the host is a secure one and thus would not reveal any sensitive information to an attacker via network interception.

Scenario 2:

The web application owners have taken all the steps to prevent cookie interception by making sure that the cookie can only be transmitted over a secure HTTPS connection and a Secure flag is also used to ensure this behaviour. But the application does not perform data validation properly and is thus vulnerable to Cross-site Scripting (XSS) attacks. It is possible for an attacker to hijack a session cookie of an authenticated user by exploiting an XSS bug within the vulnerable web application. In this case again, an attacker sends a phishing email that appears to have come from a victim's Banking web site. The email requires the user to verify the security of his account by clicking on a spoofed link within the email that exploits the XSS vulnerability within the Banking web site. As soon as a user clicks on the link, malicious client side script within the link hijacks the user session token and sends it to an attacker.

Mitigation: Microsoft had developed a 'HTTPOnly' cookie flag to prevent cookie hijacking via malicious client-side scripts. This flag was initially developed for IE6.0 but is now supported by FireFox as well. Using this flag ensures that sensitive cookies will not be accessed by any client-side side scripts, thus preventing session theft through cookie hijacking via client-side scripts. Please note that using HTTPOnly flag to prevent cookie hijacking should not be considered as an alternative to data validation to prevent XSS attack, rather it should be used in conjunction with any other measure taken to make the application secure.

By taking these two simple measures, you may be able to prevent most of the cookie hijacking attacks on your web applications.