21

The Yesod book says

The encryption prevents the user from inspecting the data, and the signature ensures that the session can be neither hijacked nor tampered with.

It's not clear to me why this is the case. If an eavesdropper gets hold of the cookie as it is sent from the server and uses it before the legitimate user makes another request, won't the session end up being hijacked?

It seems to me that the only way to really prevent session hijacking is to use SSL throughout. But if I do so then the signing and encryption done by Yesod ends up being unnecessary overhead (EDIT: overhead as far as preventing hijacking is concerned. As @sr_ points out in the comments, it is still useful otherwise).

Jyotirmoy Bhattacharya
  • 9,317
  • 3
  • 29
  • 38
  • 2
    The threat that is mitigated here is _the user changing the cookie (without the server noticing that)_, a general problem that occurs when the client is trusted too much (by saving stuff in cookies). From [hackage](http://hackage.haskell.org/package/clientsession-0.9.1/docs/Web-ClientSession.html): "Besides detecting potential errors in storage or transmission of the cookies (integrity), the MAC also avoids malicious modifications of the cookie data by assuring you that the cookie data really was generated by this server (authenticity)." – sr_ Nov 14 '14 at 11:44
  • @sr_ Agreed. What I am taking issue is with is the book's claim that the cookie cannot be hijacked. For example if I am using authentication on my site but do no use SSL on all my pages it seems to me that in the right circumstances an attacker can impersonate me to the site. – Jyotirmoy Bhattacharya Nov 14 '14 at 11:49

1 Answers1

24

That's a good catch. This used to be more accurate, when we would include the IP address of the client in the cookie to prevent hijacking. Combined with the anti-tampering protections, this made it basically impossible for a MITM attack to work unless you were NATed behind the same router or using the same proxy.

Unfortunately, we had to disable that protection due to concerns about proxies as well. It's possible for a single user's requests to come from multiple IP addresses due to intermediate proxy servers. I don't have data to tell how often this happens, but there was enough concern about this security feature causing breakage that we disabled it.

Thank you for bringing this up, I've corrected the book.

Michael Snoyman
  • 31,100
  • 3
  • 48
  • 77
  • 1
    Thanks, both for the correction and the great software. – Jyotirmoy Bhattacharya Nov 14 '14 at 12:09
  • 3
    A pleasure, feedback like this question makes the whole system much better! – Michael Snoyman Nov 14 '14 at 12:10
  • 1
    For people using AOL, it used to be the case that each user rotated through 4 IP addresses for requests. I remember disabling my IP protection stuff because of that, many many years ago. – Neil Mitchell Nov 14 '14 at 18:01
  • 3
    Just a note - even for SSL-only sites, your yesod sessions are still vulnerable to hijacking unless you a) use customizeSessionCookies to set the secure bit on the session cookie or b) set a Strict-Transport-Security header on your responses. preferably both. without at least one of these measures, I believe an attacker could impersonate your site and intercept session cookies sent by any user that tries to get to the site by http (as opposed to https) – traffichazard Nov 29 '14 at 21:33