Blog :: by Wade Woolwine

Why use the “secure” option for cookies?

Most modern web applications built on web development frameworks (PHP, Java, .NET, etc) use the cookie to store session identifiers which track a visitor’s activity throughout the site. Moreover, these session identifiers are also used when determining the visitor’s identity and authorizing transactions throughout the web application. As such, this value, which is transmitted with every HTTP request as part of the cookie, becomes a very attractive target to attackers.

To minimize the risk of exposing the session identifier on the network in cleartext the data going between the visitor’s web browser and the web application server must be encrypted using SSL. Baring any other vulnerabilities in the code such as XSS, code injection or SQLi one would assume that the session identifier is well protected…Not if the Secure only cookie flag hasn’t been set.

Per RFC 2109

The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie.

The user agent (possibly under the user’s control) may determine what level of security it considers appropriate for “secure” cookies. The Secure attribute should be considered security advice from the server to the user agent, indicating that it is in the session’s interest to protect the cookie contents.

This excerpt of the RFC simply means that if a cookie has the “Secure” option enabled, the browser must only send the cookie when the HTTP request is performed over SSL. The importance of this option is highlighted by a recent attack by Sandro Gauci of Enable Security.

In his paper (and video), Sandro demonstrates how an attacker on the same network physical network can use his tool (SurfJacking) to hijack another user’s authenticated SSL session with GMail and successfully obtain the session identifier. His approach is so simple, I regret not having thought about this myself:

1. Victim logs into GMail using SSL*.
2. Victim uses the same browser to visit another web page (while keeping the GMail window open)
3. The SurfJacking tool detects step 3 and issues a fraudulent 302 HTTP Response code (Permanently Moved) pointing to http://mail.google.com
4. The victim browser accepts the redirect and initiates a connection with http://mail.google.com using the same session identifier as was used in the SSL connection.
5. SurfJacking identifies the cleartext GMail session identifier and logs it for the tool operator.
6. Attacker accessing the victim’s GMail account.

* The browser connection setting in GMail must be set to Don’t always use HTTPS (which is the default)

Sandro Gauci has written a paper and created a video demo to illustrate the attack. The video shows the SurfJacking tool in action as well as mitigating the attack by enabling SSL only cookies with the “browser connection” setting in GMail. Please be sure to check them out.

Tags: cookies, secure, SSL, tools