Earlier quoted context omitted.
Thank you, Peter.
I was convinced of your way of thinking, eventually ;-)
I had this exact conversation with Chad Fowler once, where I was you and he was James. Now all four of us are in agreement.
Rails SQL injection vulnerability: here are the facts
61–70 of 121 posts
Re: Rails SQL injection vulnerability: here are the facts
#62Re: Rails SQL injection vulnerability: here are the facts
#63This 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.
There are a bit more vulns hanging around 'params' http://homakov.blogspot.com/2013/01/rails-security-digest-el...
Re: Rails SQL injection vulnerability: here are the facts
#64I wish ruby had named the Hash class properly. It makes reading the article slightly confusing. Hash != Hashtable
Of course the Hash class in Ruby implements a hash table. What makes you think it doesn't?
Re: Rails SQL injection vulnerability: here are the facts
#65This 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.
I can confirm that there is a generic way to exploit this. There is also a denial of service vector that is currently unpatched and depending on the way you have written your app there is a remote code execution issue as well which is unpatched (i don't think any real apps would be vulnerable to this.. but who knows). i suspect dos + rce use the same vector that tptacek has found.
Re: Rails SQL injection vulnerability: here are the facts
#66Excellent post - clear and with example.
But - I'm confused why one of the readers on the post (Jonas) is calling this a PR Stunt?
Re: Rails SQL injection vulnerability: here are the facts
#67I'm starting to wonder if the DRY-uber-alles notion popularized by Rails is turning into a security antipattern. It's just too easy for code like this (intended to "make things work cleanly") to forget all the needed checks and all the constraints on the design. The end user ends up repeating themselves less, but that means that the library code ends up getting used in lots of places and for lots of purposes that the…
It also means that when a bug is found in that code that you only have to fix it in one place, not 75,000 random places where it's duplicated, and probably slightly differently each time, making it hard to search for.
Re: Rails SQL injection vulnerability: here are the facts
#68I'm starting to wonder if the DRY-uber-alles notion popularized by Rails is turning into a security antipattern. It's just too easy for code like this (intended to "make things work cleanly") to forget all the needed checks and all the constraints on the design. The end user ends up repeating themselves less, but that means that the library code ends up getting used in lots of places and for lots of purposes that the…
It also means that when a bug is found in that code that you only have to fix it in one place, not 75,000 random places where it's duplicated, and probably slightly differently each time, making it hard to search for.
That seems to be belied by this very case, no? Rails had two ways of doing something, one of which forgot where the input could come from...
Re: Rails SQL injection vulnerability: here are the facts
#69I wish ruby had named the Hash class properly. It makes reading the article slightly confusing. Hash != Hashtable
You can blame Perl for that. Ruby took "Hash" from Perl's name for its native hash tables.
Re: Rails SQL injection vulnerability: here are the facts
#70I wish ruby had named the Hash class properly. It makes reading the article slightly confusing. Hash != Hashtable
Of course the Hash class in Ruby implements a hash table. What makes you think it doesn't?
I believe that macca321 is wishing that, to avoid confusion, the term "hash" was reserved for referring to an individual hash code and that "hash table" was used for the data structure and the Ruby class that implements it.