Play Framework Security Advisory (opens in new tab)

I believe the whole purpose of putting session data into cookies is to prevent the other issues that arise when storing session data on the server's database. The main issue is that when you're load balancing, each request could be load balanced to a different server, so you need the session to be stored on the client side to prevent the hassle of trying to scale your back-end to use your solution.

Server based lookups have their own problems. An attacker can guess a session ID and spoof that customer. Storing hundreds of thousands of session IDs on disk or in the database can lead to performance problems. You'd leak huge amounts of information if someone were to gain access to the database or filesystem where these cookies are stored.

You can argue about solutions to each of these. My point is that each solution has their own problems. IMO, play's solution has worked well so far, making it easy to scale horizontally. I've been using play for 3 years. One security issue in 3 years, with a quick patch applied, is acceptable. Before that we used PHP, and we had many problems dealing with the huge volume of sessions to be handled.

Because signed session data is a great idea. Only slightly more data than an identifier traded for one less lookup and much higher flexibility server-side.

This implementation appears to have a bug in the signing mechanism, which is pretty bad. That's why we use existing crypto libraries.

The idea is so appealing to some because it means any host serving that web application can handle your request, rather than being forced to use "sticky sessions". Otherwise you have to move the session data into the database, which can be unappealing as well.

While I agree with you that putting session data in a cookie is a risky idea, I had a question:

> I have even written my own session handling wsgi middleware just because I don't understand encryption and cannot find a framework that doesn't try that.

You wrote your own library that stores in plaintext because you weren't sure that pre-existing libraries were doing crypto correctly?

Why couldn't you treat those other libs' ciphertext as plaintext and apply your custom security engineering to it.

I love Play, but I have also been bitten by issues when upgrading.

Needless to say, if you think 1.2.5 to 1.2.6 is bad, don't ever upgrade to 2.x!

If the issue can be caused by inserting null bytes into the session, then it sounds like the signed cookie verification might have stopped at the first null byte, allowing the attacker to place other data after the null byte which the application would continue to read and use.