7 ms·

Play Framework Security Advisory

161 points by mnml_ 13y ago

noelwelsh 13y 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.
losethos 13y ago
Two zeros is the end of a list. You must put a space-and-zero for a null. God says... had some advantage over their already dominant parents, as well as over other species; and again spreading, varying, and producing new forms. The old forms which are beaten and which yield their places to the new and victorious forms, will generally be allied in groups, from inheriting some inferiority in common; and, therefore, as new and improved groups spread throughout the world, old groups disappear from the world; and the succession of forms everywhere tends to correspond both in their first
hahame 13y ago
How is data injection possible if the session is signed?
- brown9-2 13y 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 13y 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.
lifeisstillgood 13y 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 13y 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.
  - modoc 13y 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.
    - rubinelli 13y ago
      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 13y ago
        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.
D9u 13y ago
For some reason I thought that this was about Google Play and Android devices... (crawling back under my rock now...)
dabeeeenster 13y 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 13y 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!
  - jojopotato 13y 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 =/
    - latj 13y ago
      Is scala not the templating in 1.x?
      - jojopotato 13y ago
        Apparently it's groovy, I just knew it as the templating for Play before now :) http://www.playframework.com/documentation/1.2.5/templates#syntax http://www.playframework.com/documentation/1.2.5/templates#s...
        vorg 13y ago
        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 13y ago
        Can you explain/give a link?

161 points by mnml_ 13y 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.

losethos 13y ago

Two zeros is the end of a list. You must put a space-and-zero for a null. God says... had some advantage over their already dominant parents, as well as over other species; and again spreading, varying, and producing new forms. The old forms which are beaten and which yield their places to the new and victorious forms, will generally be allied in groups, from inheriting some inferiority in common; and, therefore, as new and improved groups spread throughout the world, old groups disappear from the world; and the succession of forms everywhere tends to correspond both in their first

hahame 13y ago

How is data injection possible if the session is signed?

brown9-2 13y 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 13y 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.

lifeisstillgood 13y 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 13y 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.
- modoc 13y 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.
  - rubinelli 13y ago
    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 13y ago
      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.

D9u 13y ago

For some reason I thought that this was about Google Play and Android devices... (crawling back under my rock now...)

dabeeeenster 13y 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 13y 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!
- jojopotato 13y 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 =/
  - latj 13y ago
    Is scala not the templating in 1.x?
    - jojopotato 13y ago
      Apparently it's groovy, I just knew it as the templating for Play before now :) http://www.playframework.com/documentation/1.2.5/templates#syntax http://www.playframework.com/documentation/1.2.5/templates#s...
      - vorg 13y ago
        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 13y ago
        Can you explain/give a link?