13

I've read that the play framework solves the session fixation issue by hashing the session id with the application key, but does it provide any mechanism to prevent session hijacking, or is this left up to the implementor?

marchaos
  • 3,316
  • 4
  • 26
  • 35
  • So far I have a yes and a no, so there's obviously some conflicting information here. – marchaos Jan 05 '12 at 19:37
  • I still feel that this question is unanswered, but unfortunately I have to award the bounty in any case. If someone could reply with a definitive answer, that would be great. – marchaos Jan 23 '12 at 11:32

2 Answers2

3

The play documentation has a good section on security, so rather than duplicate, here is a link - http://www.playframework.org/documentation/1.2.4/security.

It covers

  • XSS
  • SQL Injection
  • Session security
  • Cross site request forgery

Some you have to implement yourself, others you don't.

Your specific question about session hijacking is automatic.

The session is a hash of key/values, signed but not encrypted. That means that as long as your secret is safe, it is not possible for a third-party to forge sessions.

Codemwnci
  • 54,176
  • 10
  • 96
  • 129
  • Thanks for the answer. I don't really see how hashing the key values and signing it against the application key prevents someone stealing your cookie and using it. Perhaps I'm missing something? – marchaos Jan 04 '12 at 19:22
  • because, if someone tampers with it, they do not know the hash, so the hash value becomes invalid, and Play knows the session has become invalidated. – Codemwnci Jan 04 '12 at 20:01
  • 2
    What if they don't tamper with it. If I sniff your cookie, and don't change any values within it, then surely since the hash is still valid (assuming this is stored in the cookie), I can authenticate using your values. – marchaos Jan 04 '12 at 21:24
  • they can see the values, but cannot tamper with the values. If you want to encode what goes in the cookie server side, to secure the data, you can. – Codemwnci Jan 05 '12 at 00:09
3

No, there is no built in way to prevent the hijacking of a session as soon as one is able to capture the session cookie (through sniffing/man in the middle). There are some ways to make it harder, e.g.:

  • using only https
  • setting application.session.httpOnly in application.conf

One approache to make it harder is: - store the ip/user-agent/resolution/other stuff or a hash of that also in the session.. in your controller you then check if the user that accesses your site still recreates the same hash... the only real problem is with people that are using a proxy that e.g. changes the ip on the fly because of clustering.

A little trick you could try to use: (works only in recent browsers) When a user logs in, store some stuff in a HTML5 local storage. Modify your Ajax calls to supply this information from the local storage. If the information is missing/invalid, you can invalidate the whole session. But you'll have to make sure, that the checks only get applied against requests from HTML5 browsers.

hope this helps a bit.

Dominik Dorn
  • 1,820
  • 12
  • 18
  • Storing the ip and user agent is a bad idea. See http://stackoverflow.com/questions/969330/including-user-ip-addr-for-hash-cookie-value-bad-idea – marchaos Jan 04 '12 at 21:26
  • you're link addresses what I have said with "the only real problem is with people that are using a proxy that e.g. changes the ip on the fly because of clustering." There's nothing against storing a hash of the user-agent, because if that changes during a session, the session got hijacked. It all depends on how much energy you're willing to put into this and if its really worth it. Changing/deleting sensitive data should always only be possible through SSL and providing a password. – Dominik Dorn Jan 05 '12 at 15:08