CODEWITHSUNDEEP
securitysessionplayframework
Marcin Sokolowski
Marcin Sokolowski

Reputation: 669

Session security in playframework

I've just read that Play keeps session data on client side:

It’s important to understand that Session and Flash data are not stored in the server but are added to each subsequent HTTP Request, using Cookies. This means that the data size is very limited (up to 4 KB) and that you can only store string values.

I'm not experienced in WEB, so I have a few questions:

1) It is secure?

2) How reasonable is store sensitive data in this kind of session?

it is possible for client to change request data (change session data without session id). Is there any built mechanism in Play to prevent effects of such situtions? What happend when client change session data, and after request server try to read this data?

Cookies are signed with a secret key so the client can’t modify the cookie data (or it will be invalidated).

But what does it means? Let assumed that client change session data. What happends on server side after:

String foo = session(bar)

foo will be null? Junk random string? Exception will be thrown?

Upvotes: 2

Views: 1361

Answers (1)

rook
rook

Reputation: 67019

This "RESTful" approach to sessions can be secure enough. The problem that there are more secure and faster approaches to managing sessions.

The cookie probably isn't signed. Using asymmetric cryptography for this would be a huge waste of resources. Its more likely that the cookie is protected with an Hashed Message Authentication Code or HMAC. If the developer thinks an HMAC is called "signing" you may have bigger security problems on your hands, because that word usage is clearly incorrect.

The biggest security problem with using an HMAC as a session id is that chances are you are building all of your sessions using a single secret key. This secret key can be brute forced offline using a cluster of machines, over the course of years if needed. Make sure your secret is huge, around 1,024 bytes at a bare minimum. If this secret key can be read out of a file using directory traversal or another attack then an attacker is free to build their own session state, which could lead to a full compromise.

The most secure session ID is a large random value, 32 bytes is probably enough. This number is used to pull up session state from a database. Preferably from a very fast non-relational database hosted on the local network like memcached.

From a performance perspective the HMAC approach to sessions is undesirable because it consumes additional bandwidth for every HTTP request... thus slowing down every http request and consuming client resources and your web server's bandwidth.

You should only transmit the minim needed to fulfill a request. Complexity is the enemy of security, and a large random value is very simple.

Upvotes: 4

Related Questions