Play Framework Security Advisory

http://www.playframework.com/security/vulnerability/20130806-SessionInjection

by mnml_ • 13 years ago

161 39 13 years ago

noelwelsh• 13 years ago

Note that a fix is available -- patched versions of Play are available all major releases. So it might mean a redeploy of code but it's not a big deal.

hahame• 13 years ago

How is data injection possible if the session is signed?

brown9-23• 13 years ago

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.

benmmurphy• 13 years ago

It looks like they used the null byte as a separator with the assumption that users couldn't submit a null byte. So attacker could submit a value like foo\x00user:admin and it would be serialised as user:bad\x00key:foo\x00user:admin and deserialized as key:foo, user:admin. that's my takeaway from the patch. I haven't played with it so I could be off track.

lifeisstillgood4• 13 years ago

I just do not understand why we keep persisting in putting session data into cookies.

Its between hard and impossible to build to systems perfectly that do this, whereas a server based lookup has a limited number of attacks that do not involve owning my boxes.

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.

atburrow• 13 years ago

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.

modoc3• 13 years ago

Or use sticky sessions and keep the session state server side... Much faster than rebuilding session state for every request (whether from a cookie or from a DB), especially the more complex your app and session state become.

irahul4• 13 years ago

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,

When you are load balancing, request 1 goes to web/app server 1, the app server reads the session id from the cookie and read the session from the db..the next request goes to web server 2, web server 2 reads the session id from the cookie, loads the session from the db...

Each request being load balanced to a different web/app server doesn't affect the session. You are going to read the session id from the signed cookie, and then load the session from the db which is being shared between all of your web/app servers.

lucian19002• 13 years ago

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.

lifeisstillgood4• 13 years ago

That's we use existing crypto libraries.

That's how we implement flaws in the process, around crypto libraries. The price of session-cache lookups is the price paid not to worry there is a serious undiscovered security flaw waiting for you around the corner.

Its a price you have to decide if its worth paying.

brown9-23• 13 years ago

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.

skrebbel• 13 years ago

Thanks for explaining it the clearest.

Isn't this what they invented things like Memcached and Redis for, though?

taway20122• 13 years ago

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.

lifeisstillgood4• 13 years ago

No I wrote a library that stored a UUID as a cookie, then wrote that as a keypair with the user details to a backend dbase.

No crypto, just a lookup. Yes it introduces latency. But it is as secure as my servers are.

davidrudder• 13 years ago

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.

JulianMorrison• 13 years ago

ID is random UUID, session is in Redis as an expiring key.

D9u• 13 years ago

For some reason I thought that this was about Google Play and Android devices...

(crawling back under my rock now...)

dabeeeenster• 13 years ago

Just patched some apps, and there have been other changes from 1.2.5 to 1.2.6 - not cool! In page templates,

.formatCurrency('GBP')

no longer works

nostromo• 13 years ago

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!

kaeawc• 13 years ago

2.1.x and forward has settled down a lot. They're still doing a lot of work under the hood to improve HTTP pipelining and other fun things. Worth reading their future roadmap.

https://docs.google.com/document/d/1OEt6gZ3a-daSkNXqXGAM4jBs...

jojopotato2• 13 years ago

Moving to 2.x still seems like more trouble than it's worth, but maybe I'm just burnt out on learning another templating system =/

Play Framework Security Advisory

Related Stories