Rails SQL injection vulnerability: here are the facts
blog.phusion.nl
Rails SQL injection vulnerability: here are the facts
1–10 of 121 posts
Re: Rails SQL injection vulnerability: here are the facts
#2I swear I saw this same bug discussed on Reddit from some security mailing list last week, unless this is another SQL injection vulnerability with Authlogic.
Re: Rails SQL injection vulnerability: here are the facts
#3I swear I saw this same bug discussed on Reddit from some security mailing list last week, unless this is another SQL injection vulnerability with Authlogic.
You talking about this? https://github.com/binarylogic/authlogic/pull/341
It's the same thing.
Re: Rails SQL injection vulnerability: here are the facts
#4The author wastes a lot of breath refuting claims that this is a huge Rails bug, then finally comes clean 3/4 of the way in:
Other exploitable scenarios
Your code is vulnerable if you call Foo.find_by_whatever(bar), where bar can be
an arbitrary user-specified hash with symbol keys.
Re: Rails SQL injection vulnerability: here are the facts
#5The author wastes a lot of breath refuting claims that this is a huge Rails bug, then finally comes clean 3/4 of the way in: Other exploitable scenarios Your code is vulnerable if you call Foo.find_by_whatever(bar), where bar can be an arbitrary user-specified hash with symbol keys. This is a fundamental flaw that requires a very specific set of circumstances (which the Rails community is clinging to as a get out of…
> The author wastes a lot of breath refuting claims that this is a huge Ruby bug
Get your facts right first. It's not a Ruby bug. It's a Rails bug. Ruby != Rails.
Many words are used to explain how it works. That is not a refute, nowhere did I claim the bug does not exist. But the requirement for specific circumstances is a fact.
The Python pickle example is not only totally irrelevant, it is also not a security vulnerability. Pickle does exactly what it is supposed to do. You weren't supposed to unpickle arbitrary untrusted data in the first place. If you require a safer alternative, use JSON or something, but don't expect as many features as pickle provides.
In the end, whether this is a "bug" or a "huge bug" is left as an opinion. The article provides hard facts, and a little bit of commentary. Fact is, we've written a ton of Rails apps that all use find_by_* quite extensively but none turned out to be vulnerable because the case where 'foo' is a symbol hash is rare. Whether you think this is an excuse or not, I'll let you decide.
Re: Rails SQL injection vulnerability: here are the facts
#6The author wastes a lot of breath refuting claims that this is a huge Rails bug, then finally comes clean 3/4 of the way in: Other exploitable scenarios Your code is vulnerable if you call Foo.find_by_whatever(bar), where bar can be an arbitrary user-specified hash with symbol keys. This is a fundamental flaw that requires a very specific set of circumstances (which the Rails community is clinging to as a get out of…
I don't see it as a "huge Ruby bug". Could you elaborate, please?
I would understand "huge Ruby on Rails bug", though, by convention, it is still a fairly unlikely case.
Edit: I think your edit answers my "Could you elaborate" question somewhat, as you relate a Python library issue to this issue.
Re: Rails SQL injection vulnerability: here are the facts
#7The author wastes a lot of breath refuting claims that this is a huge Rails bug, then finally comes clean 3/4 of the way in: Other exploitable scenarios Your code is vulnerable if you call Foo.find_by_whatever(bar), where bar can be an arbitrary user-specified hash with symbol keys. This is a fundamental flaw that requires a very specific set of circumstances (which the Rails community is clinging to as a get out of…
> The author wastes a lot of breath refuting claims that this is a huge Ruby bug Get your facts right first. It's not a Ruby bug. It's a Rails bug. Ruby != Rails. Many words are used to explain how it works. That is not a refute, nowhere did I claim the bug does not exist. But the requirement for specific circumstances is a fact. The Python pickle example is not only totally irrelevant, it is also not a security vuln…
Thanks. Sorry, that was a freudian slip from just reading a rage tweet about Ruby vs. Rails.
Re: Rails SQL injection vulnerability: here are the facts
#8The author wastes a lot of breath refuting claims that this is a huge Rails bug, then finally comes clean 3/4 of the way in: Other exploitable scenarios Your code is vulnerable if you call Foo.find_by_whatever(bar), where bar can be an arbitrary user-specified hash with symbol keys. This is a fundamental flaw that requires a very specific set of circumstances (which the Rails community is clinging to as a get out of…
Python's Pickle is insecure by design. It causes application-specific vulnerabilities the way bad crypto libraries do, by giving developers a tool to blow their feet off with. It's hard to blame Python too much for that; languages are going to provide unsafe libraries.
This, on the other hand, is just a Rails bug. It has a simple fix. That fix is provided transparently by Rails. It isn't going to cause "lots of application specific vulnerabilities" because nobody is going to care about it 6 months from now, except as yet another reason to keep Rails at the most recent version. This is a problem no different from that faced by people on J2EE stacks.
So I disagree with both of your points.
Re: Rails SQL injection vulnerability: here are the facts
#9This post is written very confidently. I am less confident than the author of this post that the likelihood of a generic exploit via application input (that is, not using forged cookies) is remote.
Wish there was more I could say right now. I'm not saying I have a curl command that exploits the vulnerability. I'd just be careful about making assumptions about this bug.
Re: Rails SQL injection vulnerability: here are the facts
#10This post is written very confidently. I am less confident than the author of this post that the likelihood of a generic exploit via application input (that is, not using forged cookies) is remote. Wish there was more I could say right now. I'm not saying I have a curl command that exploits the vulnerability. I'd just be careful about making assumptions about this bug.
Not disagreeing with you there. After all there's no way to prove that something doesn't exist. What's why I wrote that everyone should upgrade, just in case. :)
The goal of the article is not to defend Rails. It is to inform about the nature of the vulnerability and to replace the feeling of panic with rational thoughts.