Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails SQL injection vulnerability: here are the facts

blog.phusion.nl

Post reply on HN
Print view View original

81–90 of 121 posts

Re: Rails SQL injection vulnerability: here are the facts

#81

Post by __david__ »

ajross wrote: post #72
__david__ wrote: post #71

Earlier quoted context omitted.

Hmm... How would copy-pasta code have prevented this?

I fear from your language that you aren't really interested in reasonable argument, but I'll try anyway: ActiveRecord had two variant find() interfaces, one of which tried to make it "easy" on the programmer by avoiding the need to extract an ID to do the lookup. And it went further by adding an overloaded argument syntax that allowed you to elide the first argument entirely. And it forgot that that second argument s…

Isn't that really the fault of an overloaded (as in doing too much) function API rather than a DRY related problem?

Re: Rails SQL injection vulnerability: here are the facts

#82

Post by ajross »

__david__ wrote: post #81
ajross wrote: post #72

Earlier quoted context omitted.

I fear from your language that you aren't really interested in reasonable argument, but I'll try anyway: ActiveRecord had two variant find() interfaces, one of which tried to make it "easy" on the programmer by avoiding the need to extract an ID to do the lookup. And it went further by adding an overloaded argument syntax that allowed you to elide the first argument entirely. And it forgot that that second argument s…

Isn't that really the fault of an overloaded (as in doing too much) function API rather than a DRY related problem?

Well, yes, but my point was that I see them as part of the same thing. A function (or whatever) that does lots of related things can be "DRY" if it avoids writing out all the related things longhand, or it can be "too much" if it introduces bugs.

DRY as a general philosophy to avoid cut-and-paste code is fine. But it's also an ethic that in my experience prioritizes concision at the expense of clarity. Loss of clarity is a factor in half the security bugs on the internet.

Re: Rails SQL injection vulnerability: here are the facts

#83

Post by bithive123 »

PommeDeTerre wrote: post #80
petercooper wrote: post #34

Earlier quoted context omitted.

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.

No, I disagree. The Ruby community is, generally, far more cohesive and homogeneous than the others you listed. This may partly be due to it being a relatively young community, compared to some others. 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 v…

I think you're conflating "the Ruby community" with "the kinds of people you see at RailsConf". Homogenous, maybe. Cohesive? Hardly.

I work with three other Ruby programmers, two of whom are female, and older than me (I'm 30). Your assertion that there are "few females involved" might as well be characterization of IT in general for all the evidence you present. In my experience diversity is a reflection of institutional values, not the culture of the programming languages used.

Apple hardware is tremendously popular with web developers in general, and while I don't blame you for your impression (I've been to RailsConf), there are plenty of Rubyists who prefer Linux on a Thinkpad. I bet you could find rich veins of Apple hardware at almost any type of conference.

There is plenty of disagreement about the best way to do things; that's why we have both Rails and Sinatra (both of which have been imitated in Python, node.js, and more) several implementations, and lots of discussions about new language features (like refinements).

I suspect your confirmation bias means you don't even notice Rubyists who don't fit your preconceptions.

Re: Rails SQL injection vulnerability: here are the facts

#84

Post by lobster_johnson »

phillmv wrote: post #19
PommeDeTerre wrote: post #12

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…

I'm surprised people are still making these arguments. Well, that's okay - don't use it then! We'll figure it out on our own. I'm interested on the "maintainability" claim, though, because that one is new to me. Are there any blog posts that make this claim with some kind of example?

The maintainability criticism is nothing new, or unique to Ruby — it has been something that has been leveled at every dynamically-typed language (eg., Python, Perl) ever since they started to become popular for writing big apps. And it's still untrue.

It comes from prejudice and fear about the lack of compile-time checks in dynamic languages. I know this personally, because I remember starting out with Python, and Java and C++ felt very safe — on a visceral level — in comparison, and Python felt very unsafe. I have since learned to recognize these feelings as irrational and unfounded.

Any language allows you to shoot yourself in the foot, in different ways. It's just as easy to write an unmaintainable app in C++ as it is in Ruby.

Re: Rails SQL injection vulnerability: here are the facts

#85

Post by tptacek »

bstar77 wrote: post #47
PommeDeTerre wrote: post #12

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…

How on earth is the article smug? The author responded to the controversy with clear and concise examples demonstrating that the issue is relatively minor and very easy to address if you think you are susceptible. Additionally, most people seem to be using Devise over Authlogic now-a-days. Not saying it's ok to have bugs surfaced in less popular gems, but this thing isn't going to bring the internet down.

The issue is not relatively minor, although I think the author wrote this article in good faith not realizing how non-minor it is.

Re: Rails SQL injection vulnerability: here are the facts

#86

Post by tptacek »

jrochkind1 wrote: post #53

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…

This is a comment written under the confident assumption that the Phusion article is correct. I think the article is wrong, and wrong in a way that more or less invalidates this whole comment.

You should take this bug very seriously, and also pay close attention to Rails security releases for the next couple of weeks.

Re: Rails SQL injection vulnerability: here are the facts

#87

Post by tptacek »

trustfundbaby wrote: post #73
jrochkind1 wrote: post #53

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

It's not an "SQL injection" vulnerability; it's a logic error that happens to impact the database rather than, say, OS command execution or file handling or the object space. If you're trying to get a handle on what the actual security issues and trends are with Rails, the "SQL" in the title of this vulnerability is very misleading.

Re: Rails SQL injection vulnerability: here are the facts

#88

Post by freshhawk »

petercooper wrote: post #34
PommeDeTerre wrote: post #12

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.

How is this not an argument against the existence of any type of "community"?

Of course there are Ruby, C and PHP communities. They do not include every single person and they can be more or less homogeneous when compared to each other.

Ask the people who are trying to build healthy communities around a new language or project if they think that these don't exist or don't matter or can't be worse or better than other communities.

Re: Rails SQL injection vulnerability: here are the facts

#89

Post by tptacek »

jrochkind1 wrote: post #76
trustfundbaby wrote: post #73

Earlier quoted context omitted.

> 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

That's potentially legit (people could argue about whether these rails vulnerabilities represent something to worry about in Rails, or whether even mature robust projects will still have bugs, including security bugs). 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 goi…

I wish you'd stop telling people how dangerous you're sure this vulnerability is. I think you're probably wrong, but, more importantly, I think the only reason you're saying it is that you're echoing a meme started in an article by someone who isn't really involved in the research behind the vulnerability.

Re: Rails SQL injection vulnerability: here are the facts

#90

Post by tptacek »

ajross wrote: post #54

I'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…

The vulnerability here was caused by deliberately introduced complexity --- features for features sake. You're tempted to blame the dynamic finders (which have fallen far out of fashion anyways) but really the issue here is Rails parameter handling, which was not designed to minimize typing for Ruby programmers.
Post reply on HN