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.

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.

Want to learn more?? The InfoSec Institute CISSP Training course trains and prepares you to pass the premier security certification, the CISSP. Professionals that hold the CISSP have demonstrated that they have deep knowledge of all 10 Common Body of Knowledge Domains, and have the necessary skills to provide leadership in the creation and operational duties of enterprise wide information security programs.

InfoSec Institute's proprietary CISSP certification courseware materials are always up to date and synchronized with the latest ISC2 exam objectives. Our industry leading course curriculum combined with our award-winning CISSP training provided by expert instructors delivers the platform you need in order to pass the CISSP exam with flying colors. You will leave the InfoSec Institute CISSP Boot Camp with the knowledge and domain expertise to successfully pass the CISSP exam the first time you take it. Some benefits of the CISSP Boot Camp are:

  • Dual Certification - CISSP and ISSEP/ISSMP/ISSAP
  • We have cultivated a strong reputation for getting at the secrets of the CISSP certification exam
  • Our materials are always updated with the latest information on the exam objectives: This is NOT a Common Body of Knowledge review-it is intense, successful preparation for CISSP certification.
  • We focus on preparing you for the CISSP certification exam through drill sessions, review of the entire Common Body of Knowledge, and practical question and answer scenarios, all following a high-energy seminar approach.

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)