HSTS preventing MiTM cookie hijacking attacks

Question

I was watching the following presentation:

https://www.youtube.com/watch?v=jYcx7WtbB0A

It addressed the issue when trying to access a particular web site that is available over both HTTP and HTTS and that the initial request will be send via HTTP hence exposing cookies to eavesdropping /MiTM attacks and how HSTS can address this type of issues.

The ultimate solution would be to have ALL content to be served via HTTPS so that no packet exchange is made via HTTP at all, or will it not block it?

But for HSTS to work in a mixed HTTP/HTTPS scenario each page that I’m requesting (the browser will default to HTTP) will have to be available via HTTPS as well, right ? If it’s not, HSTS will not allow to make an HTTP connection at all?

Also if you look at 8:22 in the movie there’s an illustration of the process while accessing a site (google.com in his example) where a cookie is sent with the first GET request via HTTP, could someone please verify:

a) This would only happen if the web site is available vi HTTP and HTTPS and a redirect is sent upon the initial GET request from client and where HSTS is not in place (and I have a cookie for that web site already on my laptop), right ? b) In a scenario where I’m accessing the same page for the very first time from a different computer even without HSTS enabled , there’s no risk because I don’t have a cookie from the web server yet, so no cookie will be sent with the initial HTTP GET request, correct ? c) Quoting from https://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html

Because HSTS directives are delivered via an HTTP header (over an HTTPS connection), HSTS can only instruct a browser to only use HTTPS after the browser's first visit to a secure website.>

But wouldn’t this create a door for MiTM attacks and cookie hijacking in case ONLY when the web server does not send a redirect to the client but continues via HTTP? I mean in the initial client GET HTTP request we’re not sending any cookie, the server sends it, so wouldn’t the web server send it via HTTPS to the client ?

Thanks

T

Answer 1

If you are visiting a web page for the first time, even if it uses HSTS, you are at risk of MiTM attacks as the initial connection is made over HTTP and tools like sslstrip can be used to exploit that (by basically forcing you to stay on HTTP). But if you have already visited a page before and your browser is aware that that is a HSTS page, than sslstrip will not work.

Most major browsers even have preloaded lists of some HSTS sites, which means that even if you visit a site from that list for the first time, you are protected against MiTM attacks.

Answer 2

each page that I’m requesting [...] will have to be available via HTTPS as well, right ? If it’s not, HSTS will not allow to make an HTTP connection at all?

Right. If you enable HSTS, you need to support HTTPS for all pages. If you set the includeSubDomains directive - which is recommended - all subdomains must also support HTTPS.

a) This would only happen if the web site is available vi HTTP and HTTPS and a redirect is sent upon the initial GET request from client and where HSTS is not in place (and I have a cookie for that web site already on my laptop), right

No. It doesn't matter what is available. Even if no HTTP is available, you can still send the request, thus disclosing information to a passive man in the middle.

An active man in the middle could also intercept the HTTP request, forward it as HTTPS request to the server, read the response, and send that back to you as HTTP request.

In a scenario where I’m accessing the same page for the very first time from a different computer even without HSTS enabled , there’s no risk because I don’t have a cookie from the web server yet, so no cookie will be sent with the initial HTTP GET request, correct ?

Yes, if you don't send sensitive information, no sensitive information will be exposed. But as mentioned above, it's still not secure, as you are susceptible to active man in the middle attacks.

But wouldn’t this create a door for MiTM attacks and cookie hijacking in case ONLY when the web server does not send a redirect to the client but continues via HTTP? I mean in the initial client GET HTTP request we’re not sending any cookie, the server sends it, so wouldn’t the web server send it via HTTPS to the client ?

An active man in the middle could simply not send you the redirect to HTTPS, thus forcing you to keep communicating over HTTP.

For a passive man in the middle, this is mostly true. A problem exists if cookies live longer than HSTS and the user didn't visit the page for a while. Then, their first request may be via HTTP, thus disclosing a cookie.

Some of the above mentioned issues can be avoided by setting your cookie as secure, thus disallowing sending them via HTTP in the first place.

Answer 3

MITM is not an issue

If it truly is your first visit to an HSTS site, you won't have any cookies yet. You have to actually visit a site in order for it to set a cookie for you. When you do so, the site will immediately redirect you to the https version, and in 99% of cases it won't have set a cookie (the redirection to https happens upstream of application logic, e.g. in redirect rules on the firewall or in IIS preprocessing). Even if for some reason it does set a cookie, if it is meant to be secure it will have the secure flag set, which tells your browser not to present the cookie over http.

Session fixation is an issue

On that initial http call, you might hit a malicious site acting as MitM, and it may set a cookie. In this case the cookie is already known by the hacker anyway, so there is no concern about leaking that cookie value to a malicious party. However, there is another concern: the cookie could be used to launch a session fixation attack. I this attack, the sets cookie to his own session ID (he has logged on somewhere else and sniffed the cookie). When you log on, if the web site doesn't reset the cookie, the two of you will effectively share a session, meaning he will possibly be able to see your data or execute transactions on your behalf.