I'm writing a web app that already uses TLS encrypted connections (HTTPS),
Secure; HttpOnly session cookie, HMAC-SHA1 CSRF token, requires correct
Referer header to avoid Login CSRF and changes session id during login to avoid basic session fixation attacks.
However, I cannot use HSTS because the same domain needs to serve some HTTP content for historical reasons.
I'm failing to understand how to avoid MitM attack that accomplishes session fixation in practice:
- Attacker navigates to
https://example.com/loginand receives a new anonymous
session-idcookie and corresponding HMAC-SHA1
csrf-tokenembedded in login form.
- Attacker completes login and the server overwrites the
session-idcookie for the new user id.
- Attacker saves the value of
- Victim navigates to
example.comusing HTTP and the attacker initiates MitM attack that modifies the response to have
- Victim's browser now completes full TLS handshake with
Cookie: session-id=<value-from-attacker-session>. In practice, this is a completion of session fixation attack because Victim is now running the session shared with the Attacker.
Granted, this is not an easy attack because it requires active MitM attack and the Victim needs to use initial HTTP connection to
example.com. In addition, this only allows for session fixation, not session hijacking.
- Is HSTS the only way to avoid this attack?
- Is there any way to avoid cookies set via HTTP connection being visible on HTTPS connection looking identical to
I'm assuming following claims are true:
- TLS connection is secure and the UA has a sane list of trusted CAs.
- End user is able to avoid
sslstrip-like attacks where browser chrome contains incorrect URL.
example.comis not on the preloaded HSTS list.
The guard cookie suggested by Steffen Ullrich would fix the issue except for the fact that it cannot detect if attack is done during initial connection. Implementing guard cookie would still avoid attack switching the session on-the-fly. Currently MitM Attacker could overwrite the original
Secure; HttpOnly cookie called
session-id with a regular HTTP cookie any time in the future he can get the UA to access any HTTP URL for the same domain. (This can be pretty easy because the Attacker can redirect any HTTP connection from the same browser session.)
I'm still failing to see any way to really fix this without any assistance from UA. If UAs only had a way to tell which cookies have been set over TLS connection instead of plain old HTTP...
(As a side not I have to say that all the suggestions to detect