Secure Cookies with HttpOnly and secure Flags

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

HTTPS is a secure version of HTTP – it uses SSL / TLS to protect application layer data. When using HTTPS, the following properties are achieved: audit ς, ακεραιότητα δεδομένων και εμπιστευτικότητα.

How do HTTP and HTTPS relate to secure cookie flags?

Consider the case of an authentication cookie. As mentioned earlier, stealing this cookie is tantamount to impersonating the user. When you use HTTP, the cookie is sent as plain text. This is good for the intruder who monitors the communication channel between the browser and the server - it can catch 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, an attacker could take advantage of the fact that the site is also available over HTTP. An attacker could send the link to the HTTP version of the site to the user. The user clicks on the link and the HTTP request is generated. As the HTTP traffic is sent in plain text, the attacker monitors the communication channel and reads the user 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.

Ας συνεχίσουμε την ιστορία με το cookie ελέγχου ταυτότητας και ας υποθέσουμε ότι μια ευπάθεια XSS (cross-site ) 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. The Best Technology Site in Greecefgns

Subscribe to via Email

Subscribe to this blog and receive notifications of new by email.

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.).