5

Websites has various methods implemented to tell browser to always use HTTPS - HSTS header, server redirec to HTTPS, CSP policy. However, the first time a user visits the site it can be over palin HTTP. Only after then browser knows that the site should be over TLS will it always use it.

But what if an attack has access to traffic during the first visit, and is acting like man in middle?

For instance, the attacker could perform a session fixation attack. The attacker visits the site, and gets assigned a cookie with a session id. When the user visits the site over HTTP, the attacker responds on behalf of the server and assigns his cookie to the user. Then the attacker lets all traffic through onwards. The user makes requests with the attacker's session id, give away information and so on. Now the attacker can make requests with that id and get the user's information.

What can be done to stop this kind of attack?

  • 1
    When the user authenticates after the connection was upgraded from HTTP to HTTPS, the server should assign a new session cookie, making the attacker unable to use the cookie imposed over the plain HTTP connection to access the user's session. – Arminius Mar 12 '18 at 21:17
  • that does help in few scenarios, but if attacker already logged in as himself and then assigned cookies to user, there won't be need to login. so no renewing of session – Muhammad Umer Mar 12 '18 at 21:19
  • The server might send a cookie (different from session cookie) with secure flag (i.e. https only). The attacker needs to strip this flag from the cookie when doing a sslstrip attack so that the victim will actually use this cookie. The server can later (after the attacker left the scene) check if the cookie is available through http and https and thus can detect if the secure flag was stripped from the cookie because of an attack. If this is the case the current session should be considered compromised. – Steffen Ullrich Mar 12 '18 at 21:29
  • @SteffenUllrich OP wants to impose a valid session cookie on the user when they first connect via HTTP and then upgrade the connection. The user will continue the session with the attacker's session cookie and the server can't tell the cookie was set over HTTP. A secure flag can - inexplicably - also be set from HTTP. – Arminius Mar 12 '18 at 21:32
  • 1
    @Arminius: I understand the question different and as a follow-up to How do you prevent sending cookie data over http the first time?: There is no real desire to actually send the initial cookie over HTTP. But the OP acknowledges that an attacker might use sslstrip to make the user use HTTP instead of HTTPS. – Steffen Ullrich Mar 12 '18 at 21:38
1

Assuming that you always redirect the user from HTTP to HTTPS, you can put your session identifier in a secure HTTP-Only cookie which the server never sends via HTTP.

Actually, in my case the HTTP to HTTPS happens in Apache, so my server code just can't send the cookie to a user with HTTP only.

At least, this will work in the scenario you described in your question. However, I've never heard of a MITM attack that stops at the first request. The HTTPS requests can also be proxied by the MITM so at that point the hacker gets the secure cookie anyway.

As mentioned by StackzOfZtuff, you could force requests to only be done in HTTPS by registering your site with HSTS by adding this HTTP header:

 Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Of course, that means you need to make sure that you have a valid certificate at all time or your site won't be accessible for a while. You may also not want to include sub-domains.

With HSTS, the first HTTP request never happens (at least from browsers that understand that HSTS list. But more and more browsers are now first testing with HTTPS instead of HTTP when the protocol was not specified.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.