When usesται το πρωτόκολλο HTTP, η κυκλοφορία αποστέλλεται σε απλό κείμενο. Επιτρέπει στον εισβολέα να βλέπει / τροποποιεί την κίνηση (επίθεση Man-in-the-middle).
HTTPS is a secure version of HTTP – it uses SSL / TLS for it protection of application layer data. When using HTTPS, the following properties are achieved: authentication, data integrity, and confidentiality. 
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.
Let's continue the story with the authentication cookie and assume that a XSS (cross-site scripting) vulnerability exists in the application. The 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 it is 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 can exploit XSS and trigger 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 requests HTTP TRACE 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.
