Hacker News Reader

Comment by julian37 | Hacker News Reader

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

View on HN

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.

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.

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.

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.

I get it now. I though there was interpretation of the right hand side of the =.

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

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.

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

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.

I believe the parent was mocking Ruby for its dynamic typing, rather than what you're discussing.

Reply on news.ycombinator.com