71–80 of 121 posts
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
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...
Hmm... How would copy-pasta code have prevented this?
So yes: "copy pasta" of the id boilerplate around an AR find() call would absolutely have prevented this. Rails got slick, and got burned. DRY helped reduce "copy pasta" (sigh) but hurt security.
thanks for this, phusion. I have no idea why THIS vulnerability is getting so much attention. There have actually been OTHER Raisl vulnerabilities in the past 6-8 months which were _more dangerous_, but did not really get attention. The Rails team did NOT help by being very vague about the nature of the problem in their announcement. I imagine they were trying to not reveal the method of exploitation; but it has just…
Its getting attention because its the third SQL vulnerability in 7 months. It just feels like Rails is mature enough at this point that it shouldn't have to be going through this now
If you are scanning your code base for find_by_ 's, make sure to look at your find_all_by_ 's as well if you have them.
http://edgeguides.rubyonrails.org/4_0_release_notes.html#ext...
thanks for this, phusion. I have no idea why THIS vulnerability is getting so much attention. There have actually been OTHER Raisl vulnerabilities in the past 6-8 months which were _more dangerous_, but did not really get attention. The Rails team did NOT help by being very vague about the nature of the problem in their announcement. I imagine they were trying to not reveal the method of exploitation; but it has just…
> I have no idea why THIS vulnerability is getting so much attention Its getting attention because its the third SQL vulnerability in 7 months. It just feels like Rails is mature enough at this point that it shouldn't have to be going through this now
thanks for this, phusion. I have no idea why THIS vulnerability is getting so much attention. There have actually been OTHER Raisl vulnerabilities in the past 6-8 months which were _more dangerous_, but did not really get attention. The Rails team did NOT help by being very vague about the nature of the problem in their announcement. I imagine they were trying to not reveal the method of exploitation; but it has just…
> I have no idea why THIS vulnerability is getting so much attention Its getting attention because its the third SQL vulnerability in 7 months. It just feels like Rails is mature enough at this point that it shouldn't have to be going through this now
But the fact remains that THIS vulnerability isn't NEARLY as dangerous as some of those OTHER ones you mention in the last 7 months, but those other ones people mostly ignored, and THIS one they're going crazy thinking they need to fix right away.
What I think about the general question? Most (all?) of those Rails SQL injection bugs actually are related to a similar underlying design: Attempt to create methods with 'variable signatures', where you can give it a string OR a hash, or a list of various strings and hashes, and all of those things mean different things.
I think all of the Rails SQL injection bugs are actually related to variable arguments like that. When those variable argument methods were designed in Rails, it's probably safe to say nobody realized there were security implications, that it opens you up to a whole class of bugs where someone puts a hash where you expect a string and it change the semantics of the method call because your variable argument interpreting logic had some flaws. In retrospect, it's possibly not a great thing to do.
But Rails is not the only offender here, it's a pretty common design pattern in lots of ruby -- I think it's probably a mistaken one, but it is one that developers tend to like the convenience of.
This bug is pretty edge, but if there was an easy way for a user to put a symbol in the params hash the bug would be a pretty gnarly universal SQL injection vulnerability for all versions of Rails. Though if that was easy it would most likely have been caught much, much earlier as there are a multitude of find helpers that allow literal SQL to be injected.
Early versions of Rails explicitly made the decision to never symbolize user inputted hashes because symbols are never garbage collected. This would allow memory to grow unbounded. As a result Rails stores all user hash keys as strings.
thanks for this, phusion. I have no idea why THIS vulnerability is getting so much attention. There have actually been OTHER Raisl vulnerabilities in the past 6-8 months which were _more dangerous_, but did not really get attention. The Rails team did NOT help by being very vague about the nature of the problem in their announcement. I imagine they were trying to not reveal the method of exploitation; but it has just…
> I have no idea why THIS vulnerability is getting so much attention Its getting attention because its the third SQL vulnerability in 7 months. It just feels like Rails is mature enough at this point that it shouldn't have to be going through this now
Earlier quoted context omitted.
This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become…
Our Rails site successfully served 45k simultaneous requests for the National Moment of Silence two weeks ago. I call that moderate traffic, and we didn't fall over. Please stop assuming that no one can make Rails scale just because there are some popular stories of it not scaling.
You're only looking at part of the picture, I think. It's not just a matter of asking, "will the site hold up?", but rather it's one of "will the site hold up, given an economically-feasible amount of resources?"
Throwing a lot of resources at a Ruby on Rails site for one day of heavy traffic is one thing. Having to do that for years on end just to maintain a reasonable level of service in the face of growth is a very different thing, and far closer to the reality that we have to deal with.
Earlier quoted context omitted.
This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become…
Maybe. If so, it's only slightly more bearable than the attitude of many observers towards what or how they think "the Ruby community" collectively believe, do, or act. There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.
Anyone who has been to a Ruby conference, especially while not being overly involved with the community otherwise, would likely know what I'm talking about, for example.
Almost the entire community is male. There are very, very, very few females involved. While other communities have an imbalance, it is nowhere near as lopsided as it is within the Ruby community.
Another common trait is the use of Apple hardware. It's rare to see anything but Apple laptops or other devices being used by those within the Ruby community. I've been at talks where there are rows of 20 people, and over 15 of them are using a MacBook of some sort.
There's very little true dissent within the community. The emphasis on "convention over configuration" ends up chiseling those conventions into stone, and nobody dares question them, even when they're obviously wrong.
While I'm not saying every single member of the Ruby community is exactly like every other, there is a commonality that is not found in any other computing community. It's undeniable.