Secure Cookies with HttpOnly and secure Flags

When the HTTP protocol is used, traffic is sent in plain text. Allows attacker to view / modify traffic ( man-in-the-middle).

HTTPS is a secure version of HTTP - it uses SSL / TLS to protect them of the application layer. When using HTTPS, the following properties are achieved: authentication, data integrity, and confidentiality.

How do HTTP and HTTPS relate to secure cookie flags?

Let's consider the case of an authentication cookie. As said before, the of this cookie is equivalent to user impersonation. When using HTTP, the cookie is sent as plain text. This is good for an attacker monitoring the communication channel between the browser and the server – they can grab the cookie and impersonate the user.

Now suppose that HTTPS is used instead of HTTP. HTTPS provides confidentiality. That's why the attacker can't see the cookie. So you can send the authentication cookie over a secure channel so it can't be 'caught'.

So the question is: why do we need a secure flag if we can use HTTPS?

Let us consider the following scenario to answer this question. A website is available via HTTP and HTTPS. In addition, suppose there is an intruder in the middle of the communication channel between the browser and the server. The cookie sent via HTTPS cannot be violated.

However, the attacker can take advantage of the fact that the website is also available via HTTP. The attacker can send the link to the HTTP version of the website to the user. The user does in the link and the HTTP request is generated. Since HTTP traffic is sent in plain text, the attacker monitors the communication channel and reads the user's authentication cookie.

Can we allow this cookie to be sent only via HTTPS? If this were possible, we would prevent the attacker from reading the authentication cookie in our history. It turns out that one is possible secure flag used for this purpose - the secure flag cookie will only be sent via an HTTPS connection.

HttpOnly Flags

We have seen how to protect the cookie from an attacker who monitors the communication channel between the browser and the server. However, eavesdropping is not the only way to attack a cookie.

Let's continue the authentication cookie story and assume that a XSS (cross-site scripting) exists in the application. An attacker can then exploit the vulnerability and steal the authentication cookie.

Can we somehow prevent this from happening? 

A HttpOnly flag can be used to resolve this issue. When using the HttpOnly flag, JavaScript will not be able to read the authentication cookie in the event of an XSS attack.

But the problem may still exist when there is a cross-site tracing (XST) vulnerability (this vulnerability will be explained in the next section of the article) - an attacker could exploit XSS and enable the TRACE method to read the authentication cookie even if the HttpOnly flag is used.

Let's see how XST works.

XST to bypass Flags HttpOnly

GET and POST are the most commonly used HTTP methods. However, they are not the only ones. Among other things is the HTTP TRACE method that can be used for debugging purposes. When the TRACE request is sent to the server, it is redirected to the browser (if TRACE is enabled).

The authentication cookie is sent to HTTP TRACE requests even if Flag HttpOnly is used. So the attacker needs a way to send an HTTP TRACE request and then read the response.

Here, an XSS vulnerability might be useful. Suppose the application is vulnerable to XSS. The attacker can then enter the script that sends the TRACE request. When the answer arrives, the script extracts the authentication cookie and sends it to the attacker. This way, the attacker can snatch the authentication cookie even if Flag HttpOnly is being used. As we have seen, the HTTP TRACE method was combined with XSS to read the authentication cookie, even if the Flag HttpOnly is used. The combination of HTTP TRACE and XSS is called cross-site tracing (XST).

Modern browsers block the HTTP TRACE method in XMLHttpRequest. This is why the attacker has to find another way to send an HTTP TRACE request.

One could say that XST is quite old and not worth mentioning. In my opinion, it is good to know how XST works. If the attacker finds another way to send HTTP TRACE, then it can bypass the HttpOnly Flag. In addition, the ability / inability to send an HTTP TRACE request depends on the browser - it would be better to disable HTTP TRACE to make XST impossible.

iGuRu.gr The Best Technology Site in Greecefgns

every publication, directly to your inbox

Join the 2.100 registrants.

Written by Anastasis Vasileiadis

Translations are like women. When they are beautiful they are not faithful and when they are faithful they are not beautiful.

Leave a reply

Your email address is not published. Required fields are mentioned with *

Your message will not be published if:
1. Contains insulting, defamatory, racist, offensive or inappropriate comments.
2. Causes harm to minors.
3. It interferes with the privacy and individual and social rights of other users.
4. Advertises products or services or websites.
5. Contains personal information (address, phone, etc.).