1. Introduction

Securing cookies is an important subject. Think about an authentication cookie. When the attacker is able to grab this cookie, he can impersonate the user. This article describes HttpOnly and secure flags that can enhance security of cookies.

2. HTTP, HTTPS and secure Flag

When HTTP protocol is used, the traffic is sent in plaintext. It allows the attacker to see/modify the traffic (man-in-the-middle attack). HTTPS is a secure version of HTTP – it uses SSL/TLS to protect the data of the application layer. When HTTPS is used, the following properties are achieved: authentication, data integrity, confidentiality. How are HTTP and HTTPS related to a secure flag of the cookie?

Let’s consider the case of an authentication cookie. As was previously said, stealing this cookie is equivalent to impersonating the user. When HTTP is used, the cookie is sent in plaintext. This is fine for the attacker eavesdropping on the communication channel between the browser and the server – he can grab the cookie and impersonate the user.

Now let’s assume that HTTPS is used instead of HTTP. HTTPS provides confidentiality. That’s why the attacker can’t see the cookie. The conclusion is to send the authentication cookie over a secure channel so that it can’t be eavesdropped. The question that might appear in this moment is: why do we need a secure flag if we can use HTTPS?

Let’s consider the following scenario to answer this question. The site is available over HTTP and HTTPS. Moreover, let’s assume that there is an attacker in the middle of the communication channel between the browser and the server. The cookie sent over HTTPS can’t be eavesdropped. However, the attacker can take advantage of the fact that the site is also available over HTTP. The attacker can send the link to the HTTP version of the site to the user. The user clicks the link and the HTTP request is generated. Since HTTP traffic is sent in plaintext, the attacker eavesdrops on the communication channel and reads the authentication cookie of the user. Can we allow this cookie to be sent only over HTTPS? If this was possible, we would prevent the attacker from reading the authentication cookie in our story. It turns out that it is possible, and a secure flag is used exactly for this purpose – the cookie with a secure flag will only be sent over an HTTPS connection.

3. HttpOnly Flag

In the previous section, it was presented how to protect the cookie from an attacker eavesdropping on the communication channel between the browser and the server. However, eavesdropping is not the only attack vector to grab the cookie.

Let’s continue the story with the authentication cookie and assume that XSS (cross-site scripting) vulnerability is present in the application. Then the attacker can take advantage of the XSS vulnerability to steal the authentication cookie. Can we somehow prevent this from happening? It turns out that an HttpOnly flag can be used to solve this problem. When an HttpOnly flag is used, JavaScript will not be able to read this authentication cookie in case of XSS exploitation. It seems like we have achieved the goal, but the problem might still be present when cross-site tracing (XST) vulnerability exists (this vulnerability will be explained in the next section of the article) – the attacker might take advantage of XSS and enabled TRACE method to read the authentication cookie even if HttpOnly flag is used. Let’s see how XST works.

4. XST to bypass HttpOnly flag

GET and POST are the most commonly used methods by HTTP. However, there are not the only ones. Among the others is HTTP TRACE method that can used for debugging purposes. When the TRACE request is sent to the server, it is echoed back to the browser (assuming that TRACE is enabled). It is important here, that the response includes the cookie sent in the request.

Let’s continue the story of the authentication cookie from previous sections. The authentication cookie is sent in HTTP TRACE requests even if the HttpOnly flag is used. The attacker needs a way to send an HTTP TRACE request and then read the response. Here, XSS vulnerability can be helpful. Let’s assume that the application is vulnerable to XSS. Then the attacker can inject the script that sends the TRACE request. When the response comes, the script extracts the authentication cookie and sends it to the attacker. This way the attacker can grab the authentication cookie even if the HttpOnly flag is used.

As we have seen, the HTTP TRACE method was combined with XSS to read the authentication cookie, even if the HttpOnly flag is used. The combination of HTTP TRACE method and XSS is called cross-site tracing (XST) attack.

Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

  • Get CWAPT Certified
  • Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
  • Learn how to exploit and defend real-world web apps: not just silly sample code
  • Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
  • Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance

It turns out that modern browsers block the HTTP TRACE method in XMLHttpRequest. That’s why the attacker has to find another way to send an HTTP TRACE request. One may say that XST is quite historical and not worth mentioning. In my opinion, it’s good to know how XST works. If the attacker finds another way of sending HTTP TRACE, then he can bypass the HttpOnly flag when he knows how XST works. Moreover, the possibility/impossibility of sending an HTTP TRACE request is browser-dependent – it would just be better to disable HTTP TRACE and make XST impossible. Finally, XST is a nice example that shows how an attacker might use something that is considered to be harmless itself (enabled HTTP TRACE) to bypass some protection offered by the HttpOnly flag. It reminds us that details are very important in security, and the attacker can connect different pieces to make the attack work.

5. Summary

Security of cookies is an important subject. HttpOnly and secure flags can be used to make the cookies more secure. When a secure flag is used, then the cookie will only be sent over HTTPS, which is HTTP over SSL/TLS. When this is the case, the attacker eavesdropping on the communication channel from the browser to the server will not be able to read the cookie (HTTPS provides authentication, data integrity and confidentiality).

When HttpOnly flag is used, JavaScript will not be able to read the cookie in case of XSS exploitation. It was also presented how the combination of HTTP TRACE method and XSS might be used to bypass HttpOnly flag – this combination is cross-site tracing (XST) attack. It turns out that modern browsers block the HTTP TRACE method in XMLHttpRequest. However, it’s still important to know how XST works. If the attacker finds another way of sending HTTP TRACE, then he can bypass an HttpOnly flag when he understands how XST works.