
Play Framework Security Advisory - mnml_
http://www.playframework.com/security/vulnerability/20130806-SessionInjection
======
lifeisstillgood
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
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.

~~~
modoc
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.

~~~
rubinelli
In my experience, sticky sessions open a whole new can of worms. With proxies
and VLAN, it's very easy to have an extremely unbalanced load if you use naive
IP-based balancing. If one of the servers becomes a "hot spot", adding more
servers won't immediately remove the load from that. And when a server dies,
the sessions in that server are lost. These problems can be mitigated with an
in-memory distributed database overlaid on top of your cluster, but that opens
its own can of worms...

~~~
modoc
Apache and nginx both have an array of good LB algos. I've never seen IP-based
LB or hot-spots really. Most app servers support session replication/backup to
other node(s). This is really standard stuff in JBoss for instance (my world).
Problems that have been solved for years and used at massive scale.

------
dabeeeenster
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
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!

~~~
jojopotato
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 =/

~~~
latj
Is scala not the templating in 1.x?

~~~
jojopotato
Apparently it's groovy, I just knew it as the templating for Play before now
:)

[http://www.playframework.com/documentation/1.2.5/templates#s...](http://www.playframework.com/documentation/1.2.5/templates#syntax)

~~~
vorg
They needed to ditch Groovy for Play 2.

Seems the Android guys are facing the same problems with Groovy in their
Gradle based build system, and the Gradle team are considering switching to
Scala for Gradle 2 to keep Android on board.

~~~
happy_dino
Can you explain/give a link?

------
D9u
For some reason I thought that this was about _Google Play_ and Android
devices...

(crawling back under my rock now...)

------
noelwelsh
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
How is data injection possible if the session is signed?

~~~
brown9-2
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
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.

