Learn how to fight malware
Any program that runs can be disassembled, but that doesn’t mean it’s going to be easy. In this skills course you’ll learn
⇒ Anti-Debugging Techniques
⇒ Detecting Debuggers
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.
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.
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?
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.
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).
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.