I posted a question in the other thread: http://news.ycombinator.com/item?id=5171025

Turns out the matches are determined by the beginning character of the string column. For example, if the user's token is '5feZas0352f', the query

  SELECT * FROM users WHERE reset_token = 5;

will match that user. And if it doesn't start with a number, 0 will match it.

The behaviour is documented here:

http://dev.mysql.com/doc/refman/5.6/en/type-conversion.html

> For comparisons of a string column with a number ... there are many different strings that may convert to the value 1, such as '1', ' 1', or '1a'.

What is the reasoning that the Rails team doesn't want to address it for now? Do you have a link to a forum discussion or anything?

probably because it only happens with MySQL

This is well documented and doesn't happen with good web practices. If you accept and trust user input, you fail.

Summary of the exploit: If you accept a username from a browser that is (artificially, maliciously) submitted in a typed fashion (as a number or bool), and accept it as such, implicit conversion kicks in.

Both Rails and MySQL perform implicit conversion, so if you sanity check your apps to make sure the string you get from your browser or web service is in fact a string, there is no problem.

Or do you trust your web users?

Most people used canned packages in Rails with something like Devise. Looking at the source it looks like the token is pulled right off the params:

https://github.com/plataformatec/devise/blob/master/app/cont...

The reset routine uses Rails finder mechanism to do just what the OP discusses:

https://github.com/plataformatec/devise/blob/master/lib/devi...

I don't use MySQL because for reasons just like this - so I'm not all that surprised. That said - it would be interesting to see Devise put to the test to see if it is indeed a problem for Devise.

This is not, however, a Rails issue.

Looks like Koz just posted this: https://groups.google.com/group/rubyonrails-security/msg/1f3...