Securing cookies with httponly and secure flags [updated 2020]

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.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Http, https and secure flag

When the 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 and 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.

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.

XST to bypass the httponly flag

GET and POST are the most commonly used methods by HTTP. However, there are not the only ones. Among the others is the HTTP TRACE method that can be 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 the HTTP TRACE method and XSS is called a cross-site tracing (XST) attack.

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.

FREE role-guided training plans

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

Download Now

Conclusion

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 the HttpOnly flag is used, JavaScript will not be able to read the cookie in case of XSS exploitation. We also looked at how the combination of HTTP TRACE method and XSS might be used to bypass HttpOnly flag — this combination is a 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.