Hacker News Reader

Comment by michiel3 | Hacker News Reader

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.

View on HN

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.

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

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.

Reply on news.ycombinator.com