The recent Github attack and data binding

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The recent Github attack and data binding

Andrew Todd
Referencing this: https://gist.github.com/1978249

Grails is vulnerable to similar attacks through automatic form
binding. Is anyone else re-considering whether this should continue to
be so easy to use in Grails? Thanks.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Nathan Wells
Well, the relative silence from the dev team is a little discouraging...

I would be satisfied with a new static closure to refer to which parameters are update-able via auto data binding. It would be nice, also, if such a closure was required to make auto data binding work. I know this is a pain for people quickly prototyping stuff, but I've come to expect security by default, even at the cost of my dev speed. Of course, there's no reason adding a single line of code should slow me down either, if it's well documented.

Nathan Wells


On Mon, Mar 5, 2012 at 10:27 AM, Andrew Todd <[hidden email]> wrote:
Referencing this: https://gist.github.com/1978249

Grails is vulnerable to similar attacks through automatic form
binding. Is anyone else re-considering whether this should continue to
be so easy to use in Grails? Thanks.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Chris Polderman
In reply to this post by Andrew Todd

Maybe the fact that github is written in rails (not grails) has something to do with it?

Chris

Op 5 mrt. 2012 18:27 schreef "Andrew Todd" <[hidden email]> het volgende:
Referencing this: https://gist.github.com/1978249

Grails is vulnerable to similar attacks through automatic form
binding. Is anyone else re-considering whether this should continue to
be so easy to use in Grails? Thanks.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

bobbywarner
In reply to this post by Nathan Wells
I added a note to the scaffolding controller code (save and update actions) yesterday: https://github.com/grails/grails-core/pull/169

// TODO: Limit what properties are bound to the domain class.
// http://grails.org/doc/latest/guide/single.html#dataBinding

I decided to put comments instead of a default solution because you can do this 1 of 3 ways with Grails:  Subscript Operator, BindData, or Command Objects.

Do you think that there should be a default one included with scaffolding instead of the comments?  Please let me know.


Thanks,
Bobby
Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Chris Polderman
In reply to this post by Chris Polderman

And to correct myself: maybe it would be nice to actually read your original mail :-)

On a more serious note: it is always possible to specify the attributes to be updated like:

p.properties['firstName','lastName'] = params

This is mentioned under "security concerns" in the data binding section of the guide.

Op 5 mrt. 2012 19:35 schreef "Chris Polderman" <[hidden email]> het volgende:

Maybe the fact that github is written in rails (not grails) has something to do with it?

Chris

Op 5 mrt. 2012 18:27 schreef "Andrew Todd" <[hidden email]> het volgende:
Referencing this: https://gist.github.com/1978249

Grails is vulnerable to similar attacks through automatic form
binding. Is anyone else re-considering whether this should continue to
be so easy to use in Grails? Thanks.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

roos
In reply to this post by bobbywarner
I recommend to go a strict white-list way.
Automatic data binding should be disallowed by default on all attributes, unless the developer explicitly whitelists specific attributes.

This way, one has a little bit more to do, but imho this is the only way to ensure secure coding.
Overseeing a configuration setting (e.g. missed to blacklist an attribute) is human and will happen.



> I added a note to the scaffolding controller code (save and update actions)
> yesterday: https://github.com/grails/grails-core/pull/169
>
> // TODO: Limit what properties are bound to the domain class.
> // http://grails.org/doc/latest/guide/single.html#dataBinding
>
> I decided to put comments instead of a default solution because you can do
> this 1 of 3 ways with Grails:  Subscript Operator, BindData, or Command
> Objects.
>
> Do you think that there should be a default one included with scaffolding
> instead of the comments?  Please let me know.
>
>
> Thanks,
> Bobby
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/The-recent-Github-attack-and-data-binding-tp4446829p4447093.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Rafael Luque Leiva
In reply to this post by Nathan Wells
AFAIK Grails already provides some mechanisms against this kind of
data binding attacks. For instance, you can use a fine-grained control
of the properties bound using Command objects instead of domain
instances or the bindData method injected in controllers.

Rafael Luque

2012/3/5 Nathan Wells <[hidden email]>:

> Well, the relative silence from the dev team is a little discouraging...
>
> I would be satisfied with a new static closure to refer to which parameters
> are update-able via auto data binding. It would be nice, also, if such a
> closure was required to make auto data binding work. I know this is a pain
> for people quickly prototyping stuff, but I've come to expect security by
> default, even at the cost of my dev speed. Of course, there's no reason
> adding a single line of code should slow me down either, if it's well
> documented.
>
> Nathan Wells
>
>
>
> On Mon, Mar 5, 2012 at 10:27 AM, Andrew Todd <[hidden email]>
> wrote:
>>
>> Referencing this: https://gist.github.com/1978249
>>
>> Grails is vulnerable to similar attacks through automatic form
>> binding. Is anyone else re-considering whether this should continue to
>> be so easy to use in Grails? Thanks.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>

--
Rafael Luque

OSOCO - http://osoco.es
La empresa de los programadores profesionales

Edificio Moma
Planta 3, Loft 18
Ctra. Móstoles-Villaviciosa, Km 0,2
Móstoles, E28935 Madrid

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Andrew Todd
In reply to this post by roos
On Mon, Mar 5, 2012 at 1:44 PM, Robert Oschwald
<[hidden email]> wrote:
> I recommend to go a strict white-list way.
> Automatic data binding should be disallowed by default on all attributes, unless the developer explicitly whitelists specific attributes.
>
> This way, one has a little bit more to do, but imho this is the only way to ensure secure coding.
> Overseeing a configuration setting (e.g. missed to blacklist an attribute) is human and will happen.

This is my opinion as well. Putting a note in the "security concerns"
section of the Guide is not enough. I would venture to guess that the
current default-permissive approach is the wrong thing to do in most
situations, and it's certainly not something that should be shown in
introductory tutorials (as it often is now). Any kind of request
binding needs to be tied to a whitelist.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

bobbywarner
I didn't put a note in "security concerns," but rather directly in the scaffolding controller code that gets generated right by the save and update actions.

I agree with your points though and I'm all for making the default require whitelisting!  I'll let some others chime in before modifying my pull request.


Thanks,
Bobby
Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

rosenfeld
Rails decided for white-listing parameters as well and I agree that this
is a good resolution.

Em 05-03-2012 16:13, bobbywarner escreveu:

> I didn't put a note in "security concerns," but rather directly in the
> scaffolding controller code that gets generated right by the save and update
> actions.
>
> I agree with your points though and I'm all for making the default require
> whitelisting!  I'll let some others chime in before modifying my pull
> request.
>
>
> Thanks,
> Bobby

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Jeff Scott Brown
In reply to this post by Nathan Wells
On Mon, Mar 5, 2012 at 12:13 PM, Nathan Wells <[hidden email]> wrote:
> Well, the relative silence from the dev team is a little discouraging…
>

It looks like your response was written about 45 minutes after the
original question.  It seems unreasonable to criticize us for not
having responded to the email more quickly than that.

In any case…

We are looking for input from the community and welcome everyone's
input on possible changes.

The official user guide does point out some security concerns with
doing data binding and shows how to deal with them.  It may be that
the scaffolding code should include a comment and/or a different
approach to make the potential problem more clear to folks who don't
already understand the implications.  We are open to input.  Please
offer any suggestions.

Thanks for the help.  We appreciate it.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Jean Barmash 1
Like with many security things, there is a tension here between convenience (which is most important for prototyping) and security.  

Here is a proposal - put in a configuration setting that's enabled by default to require a whitelist for binding, but allow people to disable it when they are working on prototyping-type use cases.  Also, throw warnings into logs during startup when the insecure setting is enabled, so that when you are putting stuff into production you have clear warnings.  

Scaffolding can also be modified to use whitelists, btw. 

Thanks,

Jean


On Mon, Mar 5, 2012 at 2:42 PM, Jeff Brown <[hidden email]> wrote:
On Mon, Mar 5, 2012 at 12:13 PM, Nathan Wells <[hidden email]> wrote:
> Well, the relative silence from the dev team is a little discouraging…
>

It looks like your response was written about 45 minutes after the
original question.  It seems unreasonable to criticize us for not
having responded to the email more quickly than that.

In any case…

We are looking for input from the community and welcome everyone's
input on possible changes.

The official user guide does point out some security concerns with
doing data binding and shows how to deal with them.  It may be that
the scaffolding code should include a comment and/or a different
approach to make the potential problem more clear to folks who don't
already understand the implications.  We are open to input.  Please
offer any suggestions.

Thanks for the help.  We appreciate it.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

robelsner
On Mon, Mar 5, 2012 at 12:56 PM, Jean Barmash <[hidden email]> wrote:
...
> Here is a proposal - put in a configuration setting that's enabled by
> default to require a whitelist for binding, but allow people to disable it

Or by default in "development" environment, enable this behavior but
log a WARN when it is used.  In any other environment, disable this
behavior (with override option as you say).

Rob

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Jason Davis
In reply to this post by Jean Barmash 1
I would like a white-list, a closure in the domain. I dont care if its
enforced by default or not.

thanks,
Jason

On Mon, Mar 5, 2012 at 12:56 PM, Jean Barmash <[hidden email]> wrote:

> Like with many security things, there is a tension here between convenience
> (which is most important for prototyping) and security.
>
> Here is a proposal - put in a configuration setting that's enabled by
> default to require a whitelist for binding, but allow people to disable it
> when they are working on prototyping-type use cases.  Also, throw warnings
> into logs during startup when the insecure setting is enabled, so that when
> you are putting stuff into production you have clear warnings.
>
> Scaffolding can also be modified to use whitelists, btw.
>
> Thanks,
>
> Jean
>
>
>
> On Mon, Mar 5, 2012 at 2:42 PM, Jeff Brown <[hidden email]> wrote:
>>
>> On Mon, Mar 5, 2012 at 12:13 PM, Nathan Wells <[hidden email]> wrote:
>> > Well, the relative silence from the dev team is a little discouraging…
>> >
>>
>> It looks like your response was written about 45 minutes after the
>> original question.  It seems unreasonable to criticize us for not
>> having responded to the email more quickly than that.
>>
>> In any case…
>>
>> We are looking for input from the community and welcome everyone's
>> input on possible changes.
>>
>> The official user guide does point out some security concerns with
>> doing data binding and shows how to deal with them.  It may be that
>> the scaffolding code should include a comment and/or a different
>> approach to make the potential problem more clear to folks who don't
>> already understand the implications.  We are open to input.  Please
>> offer any suggestions.
>>
>> Thanks for the help.  We appreciate it.
>>
>>
>>
>> jb
>> --
>> Jeff Brown
>> SpringSource
>> http://www.springsource.com/
>>
>> Autism Strikes 1 in 166
>> Find The Cause ~ Find The Cure
>> http://www.autismspeaks.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Jeff Scott Brown
In reply to this post by Rafael Luque Leiva
On Mon, Mar 5, 2012 at 12:52 PM, Rafael Luque Leiva
<[hidden email]> wrote:
> AFAIK Grails already provides some mechanisms against this kind of
> data binding attacks. For instance, you can use a fine-grained control
> of the properties bound using Command objects instead of domain
> instances or the bindData method injected in controllers.
>
> Rafael Luque
>

Yes, the framework does provide simple mechanisms for managing these
concerns and those are mentioned in the user guide.

Part of what is at discussion here is really about the scaffolding.
It should represent a best practice as much as is practical and this
is a situation where we should probably improve that.  At least that
is how I see it.



jb


--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Sebastian Gozin
In reply to this post by Rafael Luque Leiva
I suspect the debate is not about there being ways to whitelist binding but that it is not the default behavior.

Personally I'm fine with the current default as I tend to end up with command objects like you just explained anyway.
I can somewhat see why people would prefer a more secure default but I feel this is a bit similar to how people feel autowiring in a Spring context is somehow not suitable for production as it might accidentally wire the wrong dependency. I have tests to catch those kinds of mistakes.

Anyway, if we do choose to default to whitelisting then earlier suggestions to only enable whitelisting in integration/production mode or through a configuration value seem very reasonable to me.

- Sebastian


On 05 Mar 2012, at 19:52, Rafael Luque Leiva wrote:

> AFAIK Grails already provides some mechanisms against this kind of
> data binding attacks. For instance, you can use a fine-grained control
> of the properties bound using Command objects instead of domain
> instances or the bindData method injected in controllers.
>
> Rafael Luque
>
> 2012/3/5 Nathan Wells <[hidden email]>:
>> Well, the relative silence from the dev team is a little discouraging...
>>
>> I would be satisfied with a new static closure to refer to which parameters
>> are update-able via auto data binding. It would be nice, also, if such a
>> closure was required to make auto data binding work. I know this is a pain
>> for people quickly prototyping stuff, but I've come to expect security by
>> default, even at the cost of my dev speed. Of course, there's no reason
>> adding a single line of code should slow me down either, if it's well
>> documented.
>>
>> Nathan Wells
>>
>>
>>
>> On Mon, Mar 5, 2012 at 10:27 AM, Andrew Todd <[hidden email]>
>> wrote:
>>>
>>> Referencing this: https://gist.github.com/1978249
>>>
>>> Grails is vulnerable to similar attacks through automatic form
>>> binding. Is anyone else re-considering whether this should continue to
>>> be so easy to use in Grails? Thanks.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>
> --
> Rafael Luque
>
> OSOCO - http://osoco.es
> La empresa de los programadores profesionales
>
> Edificio Moma
> Planta 3, Loft 18
> Ctra. Móstoles-Villaviciosa, Km 0,2
> Móstoles, E28935 Madrid
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Andrew Todd
If the goal of Web frameworks like Grails is to make it easier for
developers to write secure Web applications -- and I think it is --
then at the least requiring whitelisting in non-development modes
should happen, and happen soon.

It's in fact very disappointing to me that so many frameworks (Play is
struggling with the same issue as well) let this one slide as default
behavior. In fact, the last time I brought it up on the Grails mailing
list, several months ago, the only response I got was someone claiming
that blind request binding, as is the default in scaffolding now, was
more than "good enough" for most Web applications. So, you can't say I
didn't warn you.

Developers should have to jump through hoops to do potentially
insecure things, not the other way around. We must assume that
developers will always gravitate towards what is easiest, not what is
correct.

This whole incident has caused me to lose a lot of trust in the
"rails"-inspired frameworks. One of their primary advantages is
supposed to be sensible defaults, and restricted choices based on the
needs of the mainstream: best practices baked in from the start. And
here's a huge example of a failure.


On Mon, Mar 5, 2012 at 4:00 PM, Sebastian Gozin
<[hidden email]> wrote:

> I suspect the debate is not about there being ways to whitelist binding but that it is not the default behavior.
>
> Personally I'm fine with the current default as I tend to end up with command objects like you just explained anyway.
> I can somewhat see why people would prefer a more secure default but I feel this is a bit similar to how people feel autowiring in a Spring context is somehow not suitable for production as it might accidentally wire the wrong dependency. I have tests to catch those kinds of mistakes.
>
> Anyway, if we do choose to default to whitelisting then earlier suggestions to only enable whitelisting in integration/production mode or through a configuration value seem very reasonable to me.
>
> - Sebastian
>
>
> On 05 Mar 2012, at 19:52, Rafael Luque Leiva wrote:
>
>> AFAIK Grails already provides some mechanisms against this kind of
>> data binding attacks. For instance, you can use a fine-grained control
>> of the properties bound using Command objects instead of domain
>> instances or the bindData method injected in controllers.
>>
>> Rafael Luque
>>
>> 2012/3/5 Nathan Wells <[hidden email]>:
>>> Well, the relative silence from the dev team is a little discouraging...
>>>
>>> I would be satisfied with a new static closure to refer to which parameters
>>> are update-able via auto data binding. It would be nice, also, if such a
>>> closure was required to make auto data binding work. I know this is a pain
>>> for people quickly prototyping stuff, but I've come to expect security by
>>> default, even at the cost of my dev speed. Of course, there's no reason
>>> adding a single line of code should slow me down either, if it's well
>>> documented.
>>>
>>> Nathan Wells
>>>
>>>
>>>
>>> On Mon, Mar 5, 2012 at 10:27 AM, Andrew Todd <[hidden email]>
>>> wrote:
>>>>
>>>> Referencing this: https://gist.github.com/1978249
>>>>
>>>> Grails is vulnerable to similar attacks through automatic form
>>>> binding. Is anyone else re-considering whether this should continue to
>>>> be so easy to use in Grails? Thanks.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>
>> --
>> Rafael Luque
>>
>> OSOCO - http://osoco.es
>> La empresa de los programadores profesionales
>>
>> Edificio Moma
>> Planta 3, Loft 18
>> Ctra. Móstoles-Villaviciosa, Km 0,2
>> Móstoles, E28935 Madrid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Robert Fletcher-2
In reply to this post by Sebastian Gozin
Is there a danger of some hysteria here? The security implications of
automated form binding are pretty well documented and (I would hope)
obvious. It's surprising that GitHub got caught out by it but it's
certainly something teams I've worked on have considered ever since
using Grails. We use automated form binding but only on controllers
that are a) protected by Spring Security login and b) on a context
path that's only accessible from inside our corporate network.

Although I agree that it might be best to change current scaffolding
to be more secure I'm not in favour of making such changes in a rush.

Always using command objects is overkill for many scenarios. Even
potentially insecure controllers that bind directly to important
domain types may be better served by simply being secured with
authentication requirements.

I'm not in favour of adding a whitelist property to the domain class
as I think that's polluting the domain validation layer with form
binding concerns. It's a hack of a solution to try to keep the
controller code unchanged.

Whitelisting properties in the binding code could be clunky but if we
use a static property in the controller alongside the allowedMethods
property it might be okay. It would be easy to generate with
scaffolding.

    static final boundProperties = ['name', 'email', 'phone']

    def save() {
        def personInstance = new PersonInstance()
        bindData personInstance, params, [include: boundProperties]
        // etc.
    }

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

Robert Fletcher-2
In reply to this post by Sebastian Gozin
On Mon, Mar 5, 2012 at 9:00 PM, Sebastian Gozin
<[hidden email]> wrote:
> I can somewhat see why people would prefer a more secure default but I feel this is a bit similar to how people feel autowiring in a Spring context is somehow not suitable for production as it might accidentally wire the wrong dependency. I have tests to catch those kinds of mistakes.
>

Bingo. Couldn't agree more.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: The recent Github attack and data binding

smaldini
In reply to this post by Andrew Todd
Don't bother with binding, don't use it :) It's not good for perfs too mom said !

On Mon, Mar 5, 2012 at 10:52 PM, Andrew Todd <[hidden email]> wrote:
If the goal of Web frameworks like Grails is to make it easier for
developers to write secure Web applications -- and I think it is --
then at the least requiring whitelisting in non-development modes
should happen, and happen soon.

It's in fact very disappointing to me that so many frameworks (Play is
struggling with the same issue as well) let this one slide as default
behavior. In fact, the last time I brought it up on the Grails mailing
list, several months ago, the only response I got was someone claiming
that blind request binding, as is the default in scaffolding now, was
more than "good enough" for most Web applications. So, you can't say I
didn't warn you.

Developers should have to jump through hoops to do potentially
insecure things, not the other way around. We must assume that
developers will always gravitate towards what is easiest, not what is
correct.

This whole incident has caused me to lose a lot of trust in the
"rails"-inspired frameworks. One of their primary advantages is
supposed to be sensible defaults, and restricted choices based on the
needs of the mainstream: best practices baked in from the start. And
here's a huge example of a failure.


On Mon, Mar 5, 2012 at 4:00 PM, Sebastian Gozin
<[hidden email]> wrote:
> I suspect the debate is not about there being ways to whitelist binding but that it is not the default behavior.
>
> Personally I'm fine with the current default as I tend to end up with command objects like you just explained anyway.
> I can somewhat see why people would prefer a more secure default but I feel this is a bit similar to how people feel autowiring in a Spring context is somehow not suitable for production as it might accidentally wire the wrong dependency. I have tests to catch those kinds of mistakes.
>
> Anyway, if we do choose to default to whitelisting then earlier suggestions to only enable whitelisting in integration/production mode or through a configuration value seem very reasonable to me.
>
> - Sebastian
>
>
> On 05 Mar 2012, at 19:52, Rafael Luque Leiva wrote:
>
>> AFAIK Grails already provides some mechanisms against this kind of
>> data binding attacks. For instance, you can use a fine-grained control
>> of the properties bound using Command objects instead of domain
>> instances or the bindData method injected in controllers.
>>
>> Rafael Luque
>>
>> 2012/3/5 Nathan Wells <[hidden email]>:
>>> Well, the relative silence from the dev team is a little discouraging...
>>>
>>> I would be satisfied with a new static closure to refer to which parameters
>>> are update-able via auto data binding. It would be nice, also, if such a
>>> closure was required to make auto data binding work. I know this is a pain
>>> for people quickly prototyping stuff, but I've come to expect security by
>>> default, even at the cost of my dev speed. Of course, there's no reason
>>> adding a single line of code should slow me down either, if it's well
>>> documented.
>>>
>>> Nathan Wells
>>>
>>>
>>>
>>> On Mon, Mar 5, 2012 at 10:27 AM, Andrew Todd <[hidden email]>
>>> wrote:
>>>>
>>>> Referencing this: https://gist.github.com/1978249
>>>>
>>>> Grails is vulnerable to similar attacks through automatic form
>>>> binding. Is anyone else re-considering whether this should continue to
>>>> be so easy to use in Grails? Thanks.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>
>> --
>> Rafael Luque
>>
>> OSOCO - http://osoco.es
>> La empresa de los programadores profesionales
>>
>> Edificio Moma
>> Planta 3, Loft 18
>> Ctra. Móstoles-Villaviciosa, Km 0,2
>> Móstoles, E28935 Madrid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
Stéphane MALDINI
--


123