[2.1.1 - Scala] Question about Play and session security

[Dominykas Mostauskis]

I understand that Play encrypts session cookies; therefore they can't be edited by the client. The client sees his cookies as gibberish.

If an attacker copies client's cookies, can he effectively identify himself as that client? How to secure an application in this regard?

[Marconi Lanna]

It's called a Firesheep attack, and the only way to prevent it is to use HTTPS:

http://en.wikipedia.org/wiki/Firesheep
http://codebutler.com/firesheep/

[Will Sargent]

You can ameliorate the attack by keeping some state around on the server:

http://jaspan.com/improved_persistent_login_cookie_best_practice

I implemented this in Play already:

https://github.com/wsargent/play20-rememberme

Will.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dominykas Mostauskis]

Reading this was just short of enlightening, thanks, Will!

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/9d8W2SSRGx8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.

[James Roper]

On Thu, Sep 5, 2013 at 11:23 PM, Dominykas Mostauskis <dominykas....@gmail.com> wrote:

I understand that Play encrypts session cookies; therefore they can't be edited by the client. The client sees his cookies as gibberish.

Play does *not* encrypt session cookies.  It signs session cookies.  The cookie data is still viewable in plain text, but attached to it is a signature, and Play verifies that the signature matches the rest of the cookie data before trusting the cookie data, which prevents the cookies from being edited by the client.  The client does not see gibberish, it sees the session data, URL encoded, and the signature.  Open up your browser developer console and have a look at the request headers being sent with each request, you'll see the format of the cookie.

 

If an attacker copies client's cookies, can he effectively identify himself as that client? How to secure an application in this regard?

This is the same as for using session ids, if the attacker gets a hold of the cookie containing the session id, the attacker can identify himself as the victim.  The only way to protect against it is to protect against the avenues which the attacker may use to get the cookie:

XSS - Play enables httpOnly by default, this prevents the attacker from using an XSS attack to get the cookie (though, if the attacker can exploit an xss attack, they don't need the cookie, they can do anything the victim can do)

MITM - As mentioned by others, to protect the cookie from man in the middle attacks, you must use HTTPS.

As a best practice, you should ensure that the session cookie does not live forever.  This is one thing that you have to do yourself that you wouldn't have to do with session IDs, since session IDs require server side state and hence can be easily expired.  As mentioned by others, one way to secure this is to store some server side state, and validate the session against that.  A more scalable mechanism that doesn't require state is to store a timestamp in the session, and only accept sessions that are not older than a certain age.  Both these approaches have their advantages and disadvantages, which is right for your app very heavily depends on your app.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Dominykas Mostauskis]

Great reply. Thank you. Cleared some things up.

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/9d8W2SSRGx8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.

[Will Sargent]

What James said.  Never keep anything in the session cookie that you wouldn't be comfortable with an attacker seeing.

Also see this:

http://funcptr.net/2013/08/25/user-sessions,-what-data-should-be-stored-where-/

Will.

[fraser]

Hi All, 

We've had a security company flag an issue with this because if a user actually logs out, but someone captured the session cookie before this point. The attacker can continue using this cookie whilst it is still valid, even though the user has actually logged out and therefore terminated their session. 

They described these two different cases: 

1.       User inactivity. In the original report this is marker as “Session Timeout” and recommended at fifteen minutes. This can be extended to meet business needs/use-cases and there is some debate on what is exactly an appropriate value. For this reasons it is marked as low. During the retest I left a session for two hours and it was still active. Is there a compelling business case for this level or can it be reduced to increase security?

2.       User logs out. This is an explicate request from the user to terminate their current session, this is the new finding and is marked as “Insufficient Session Expiration”. The server should honour this immediately and expire the session. From the link the following sums this up “For the ideal secure web application, a user should be able to terminate at any time through the user interface”. This requires actions on both the client and server end (session cookie no longer valid).

The 2nd seems to require some kind of storing session information server-side (or within a distributed cache). I should note however that we were using HTTPS and this was carried out by actually using an Interception Proxy. 

What is everyone's thoughts on this? Does it seem like overkill to have to store session on the server or is this a valid security concern in this case? 

Thanks, 
Fraser 

[Will Sargent]

If you have a session cookie, you have a session cookie.  A timeout value is something that you can put into the session cookie, but Play doesn't include that logic by default. 

Storing session information in a low latency server side datastore is a great way to check that the session id is valid.  If you have private information you want to keep in your session, you want that kept server side as well.

I would checkout this link as a good reference for authentication:

https://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication

Also checkout session fixation attacks as well, which is a weakness of client only based cookies:

https://security.stackexchange.com/questions/55876/understanding-session-fixation-vulnerability

If they are using an interception proxy, then your browser is already trusting their forged certificates and is undergoing a MITM attack.  This may or may not be a reasonable attack to defend against: it depends on your threat model.

Will.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/609c3a59-014c-43f1-ae11-960681d1e966%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Sargent]

Whoops, wrong session fixation link:

https://en.wikipedia.org/wiki/Session_fixation