4 ms·

Makes me consider to start always casting URL query parameters as a defensive measure, regardless of this specific vulnerability being patched.

michiel3 14y ago
This is probably a best practice you could learn yourself to implement every time you know for sure you don't want a GET/POST variable to be a hash/array. This can also prevent other application errors when someone passes a hash/array which is used somewhere in the code where it is expected to be a string or something.
- mseebach 14y ago
  I'm not terribly familiar with the Rails feature in question, but it seems to me that GET/POST params should never be interpreted automatically. Parsing a param into any other type than a string should be explicit.
  - tptacek 14y ago
    You're (respectfully) not terribly familiar with Rails, then, because the interpretation of foo[bar]=xxx as { :foo => { :bar => 'xxx' } } is one of the core patterns in the framework. Code all across the platform depends on that behavior.
    - mseebach 14y ago
      I get it now. I though there was interpretation of the right hand side of the =.
    - sim0n 14y ago
      This is the same with PHP. Be aware anyone using something like MongoDB, if you don't sanitize/cast your inputs, your app could be vulnerable. e.g. if you have the code: $collection->findOne( array( 'username' => $_POST['username'], 'password' => $_POST['password'] ) ); someone could POST something like username[$ne]='?'&password[$ne]='?' and login.
joevandyk 14y ago
A better solution would be to have a way to indicate "this parameter needs to be this type". params[:id] could be a string, integer, hash, or array when accessed in the controller actions.
- revetkn 14y ago
  > A better solution would be to have a way to indicate "this parameter needs to be this type". If only there were some kind of concept of typing, perhaps enforced by the language and statically applied, which would eliminate this class of error entirely...boy, that would be helpful in larger systems.
  - keeperofdakeys 14y ago
    For those who don't know, these are called prepared statements. Instead of mashing strings together, you define variables in your sql string, and associate a value and type with each variable. Of course this doesn't stop bugs in the implementation, as in this case.
    - __float 14y ago
      I believe the parent was mocking Ruby for its dynamic typing, rather than what you're discussing.
joevandyk 14y ago
It's not just query parameters. Could be post params as well.

michiel3 14y ago

This is probably a best practice you could learn yourself to implement every time you know for sure you don't want a GET/POST variable to be a hash/array. This can also prevent other application errors when someone passes a hash/array which is used somewhere in the code where it is expected to be a string or something.

mseebach 14y ago
I'm not terribly familiar with the Rails feature in question, but it seems to me that GET/POST params should never be interpreted automatically. Parsing a param into any other type than a string should be explicit.
- tptacek 14y ago
  You're (respectfully) not terribly familiar with Rails, then, because the interpretation of foo[bar]=xxx as { :foo => { :bar => 'xxx' } } is one of the core patterns in the framework. Code all across the platform depends on that behavior.
  - mseebach 14y ago
    I get it now. I though there was interpretation of the right hand side of the =.
  - sim0n 14y ago
    This is the same with PHP. Be aware anyone using something like MongoDB, if you don't sanitize/cast your inputs, your app could be vulnerable. e.g. if you have the code: $collection->findOne( array( 'username' => $_POST['username'], 'password' => $_POST['password'] ) ); someone could POST something like username[$ne]='?'&password[$ne]='?' and login.

joevandyk 14y ago

A better solution would be to have a way to indicate "this parameter needs to be this type". params[:id] could be a string, integer, hash, or array when accessed in the controller actions.

revetkn 14y ago
> A better solution would be to have a way to indicate "this parameter needs to be this type". If only there were some kind of concept of typing, perhaps enforced by the language and statically applied, which would eliminate this class of error entirely...boy, that would be helpful in larger systems.
- keeperofdakeys 14y ago
  For those who don't know, these are called prepared statements. Instead of mashing strings together, you define variables in your sql string, and associate a value and type with each variable. Of course this doesn't stop bugs in the implementation, as in this case.
  - __float 14y ago
    I believe the parent was mocking Ruby for its dynamic typing, rather than what you're discussing.

joevandyk 14y ago

It's not just query parameters. Could be post params as well.