Cookies with Secure Flag: Undesired Behavior in Modern Browsers

Introduction

When a cookie has secure flag set, it will only be sent over secure HTTPS, which is HTTP over SSL/TLS. This way, the authentication cookie will not be disclosed in insecure communication (HTTP). It turns out, however, that an insecure HTTP response can overwrite a cookie with secure flag in modern browsers. As a consequence, insecure HTTP traffic can have an impact on secure HTTPS traffic, which doesn't look good from a security point of view. This undesired behavior is the subject of this article.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Secure flag and HTTP/HTTPS traffic

When HTTP is used, the attacker can see/modify the traffic. HTTPS is a secure version of HTTP – SSL/TLS is used to protect the data of the application layer. When HTTPS is used, the following properties are achieved: authentication, data integrity, and confidentiality.

The authentication cookie is very important piece of data – when the attacker grabs it, he can impersonate the user. Here, the secure flag is helpful. If the authentication cookie has secure flag set, then this cookie will only be sent over a secure HTTPS connection. As a consequence, the attacker will not be able to see this cookie. The problem is that HTTP response can overwrite a cookie with secure flag. Let's analyze this problem.

HTTP response overwriting a cookie with secure flag

Let's assume for the sake of the description that the attacker controls the communication channel and the site is available over HTTPS and HTTP. Then the attacker makes a user to send a request to the HTTP version of the site. As the attacker controls the communication channel, he injects the header Set-Cookie: in HTTP response. This way the attacker can overwrite a cookie with secure flag. This overwritten cookie will be used in the forthcoming requests sent over HTTPS. This way an insecure HTTP traffic has an impact on secure HTTPS traffic. How can that be used by the attacker?

The attacker can launch session fixation via a cookie with secure flag. As a consequence, a user will use the session ID of attacker's choice. The attacker knows this session ID and can impersonate the user. This attack will work, provided that there is no session regeneration in the application after successful login.

Another attack scenario is switching a user to the attacker's account. This attack will work even if there is session regeneration in the application after successful login – the attacker switches the user to the session that he is currently using. The user thinks that he is using his own account and enters some interesting/sensitive information into the attacker's account.

It turn out that HTTP response can overwrite a cookie with secure flag in Internet Explorer, Chrome, Firefox and Opera for example. It doesn't look good. Let's try to find the reason and see RFC 6265, which describes how secure flag works [1].

RFC 6265 and secure flag

First, let's intruduce this RFC. According to the abstract of this document:

This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.

Let's go to section 4.1.2.5 of this document (entitled The Secure Attribute) to read the information about secure flag:

The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS)[RFC2818]).

Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6 for more details).

Let's go now to Section 8.6 to get more information:

An active network attacker can also inject cookies into the Cookie header sent to https://example.com/ by impersonating a response from http://example.com/ and injecting a Set-Cookie header.

Now the puzzle is solved – this unexpected behavior exists in modern browsers because they rely on RFC 6265. And this RFC clearly says that these attacks are possible. However, it doesn't mean that it works fine from a security point of view. This is a design issue - insecure HTTP traffic should not have an impact on secure HTTPS.

Summary

When a cookie has secure flag set, it will only be sent over secure HTTPS. The problem is that HTTP response can have an impact on HTTPS traffic, which doesn't look good from a security point of view. Although it is a design issue, it is clearly written in RFC 6265, which is the one that modern browsers rely upon. As a consequence, this unexpected behavior exists in Internet Explorer, Chrome, Firefox and Opera.

Reference

[1] RFC 6265

http://tools.ietf.org/html/rfc6265 (access date: 8 August 2014)