Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Test quoting integers when comparing a string column with integers. #162
Update: the original problem was fixed by commit 93d7213, so now this just adds a regression test.
An equality with a string column and integer like
SELECT * FROM `users` WHERE `login_token` = 0 LIMIT 1;
will match any string that doesn't start with a digit in certain databases (including MySQL). However, Arel will simply treat Fixnum and Bignum as literals, and not give the connection an opportunity to quote these values.
See Potential Query Manipulation with Common Rails Practises for details on the potential security vulnerability.
Arel should allow the connection to quote integers, but needs to provide the correct column type to avoid quoting integers like the argument to LIMIT.
Quoting the integer will avoid this potential security issue in a database independent way. So the above query can be quoted as follows and only match a login_token with the exact string
SELECT * FROM `users` WHERE `login_token` = '0' LIMIT 1;
@rafaelfranca I never recommended to completely revert that pull request, only the changes to the predicate builder. Arel delegates to the connection adapters quote method for quoting, which must still must quote integers as strings for string column types.
This pull request is necessary because quoting wasn't even being delegated to the quote method for Fixnum and Bignum, and the column passed in would be irrelevant because it was never cleared.
referenced this pull request
Feb 25, 2013
Please don't underestimate the importance of this pull request. It addresses a bugs in Arel that is preventing a serious security issue from being fixed.
Attempts to work around this issue have led to regressions in rails. E.g. rails/rails#9207 has been reverted. This is the correct place to fix the issue, without any need for hacks.
Happy to merge this myself but since I'd talked with @tenderlove about it previously just wanted his input before doing so. Seems like a really good option to me, even with the shuffling of last_column. Might be able to do away with last_column altogether by continuing down this path.
So, I chatted with @tenderlove briefly and he raised a good point (one I missed, oops) which is that this exacerbates the problem we already have of mutating the visitor, which makes this code not thread-safe. It's a bigger problem to address than what we have here, but I have an idea about how we might attack it, based on some of the stuff I've done in Squeel which has worked OK. I'm going to at least try to play with it a bit this weekend and see if I get anywhere.