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

91–100 of 121 posts

Re: Rails SQL injection vulnerability: here are the facts

#91

Post by freshhawk »

dsl wrote: post #18
tptacek wrote: post #8

Earlier quoted context omitted.

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 appli…

Note that I didn't refer to the Pickle issue as a bug. I think its quite a useful feature, but it's still a pointy stick that many have fallen on.

You referred to it as a "boondoggle" which, if it wasn't even a bug, it also was not.

Re: Rails SQL injection vulnerability: here are the facts

#92

Post by derwiki »

PommeDeTerre wrote: post #79
derwiki wrote: post #58

Earlier quoted context omitted.

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.

What kind of hosting infrastructure was involved? 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 reasonab…

Colo with 17 app servers. We didn't have to spin up additional workers, and this is about half the number of web servers the last startup-turn-IPO I worked at used (and they used Python!).

Re: Rails SQL injection vulnerability: here are the facts

#93

Post by [deleted] »

PommeDeTerre wrote: post #12
tptacek wrote: post #9

This 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.

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…

[deleted]

Re: Rails SQL injection vulnerability: here are the facts

#94

Post by [deleted] »

[deleted] wrote: post #93
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…

[deleted]

[deleted]

Re: Rails SQL injection vulnerability: here are the facts

#96

Post by bstar77 »

tptacek wrote: post #85
bstar77 wrote: post #47

Earlier quoted context omitted.

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.

It's minor because it's (apparently) already been patched and because the fix takes all of about 30 seconds to fix per instance of these types of functions. SQL injection and mass assignment issues are far more serious threats than something like this, but they are not interesting because it's on the developer to secure their app.

This issue is is built up to be serious because many people seem to enjoy attacking rails and the community despite not realizing that the vast majority of the community is amazing. If there's a burning need to criticize ruby/rails, discuss Ruby's terrible garbage collection, or the state of MRI or Rails' lightspeed rate of change.

Re: Rails SQL injection vulnerability: here are the facts

#97

Post by PommeDeTerre »

[deleted] wrote: post #93
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…

[deleted]

I suspect behind your comment there's probably a bit of nagging resentment because Rails seems to have triumphed over despite Rails' Obvious Flaws -- amirite?

No, you couldn't be any more wrong. I'm not sure why you Ruby on Rails advocates always make this assumption, or accusation, any time that you encounter somebody doesn't hold a pro-Rails attitude. I saw some other commenter in this thread make the same incorrect assumption.

I couldn't even tell you exactly how many programming languages, frameworks and libraries I've worked with over my career. I've used Fortran, PL/I, COBOL, C, C++, Objective-C, Java, C#, VB, VB.NET, Python, Perl, JavaScript, and yes, even Ruby professionally at one time or another. I'm probably forgetting some, and there are also some proprietary languages I've worked with, too. I've lost track of how many different GUI, database, and web development frameworks I've encountered. Ruby on Rails is merely one among probably at least 80 to 100 frameworks that I've used at one time or another. You see, I don't really have a "preferred framework".

I do know that some communities are made up of people who hold attitudes that are, to put it mildly, quite toxic. They make claims that they cannot back up. They make serious mistakes without realizing it, and then deny it when they are pointed out. The Ruby on Rails community is like this, unfortunately. I'm not going to pretend that they aren't, either.

Re: Rails SQL injection vulnerability: here are the facts

#98

Post by PommeDeTerre »

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 attitude within your first paragraph is an excellent demonstration of the maintainability problems I'm talking about. Programmers five or ten years in the future won't have much say about the software they're being asked or told to maintain. Telling them to just "not use Ruby" won't solve the maintenance issues they're facing while working on some Rails web app developed years earlier.

I'm sure you can find numerous blog posts out there describing the maintainability problems with Rails web apps. Google for them. The fact that you're looking for blog articles makes me think that you may have limited experience with large-scale software development projects, especially those spanning many years and development teams.

Have you ever worked on large, long-running C++ or Java projects, for instance? If you have, then it should be pretty obvious to you how inadequate the maintainability of Ruby code is. Ruby, and dynamic languages in general, lack much of the functionality that makes code maintainable after many years, or even decades. I really wish you did have this sort of experience, because I think it would make the maintenance issues more more obvious.

Re: Rails SQL injection vulnerability: here are the facts

#99

Post by [deleted] »

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…

[deleted]

Re: Rails SQL injection vulnerability: here are the facts

#100

Post by tptacek »

bstar77 wrote: post #96
tptacek wrote: post #85

Earlier quoted context omitted.

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

It's minor because it's (apparently) already been patched and because the fix takes all of about 30 seconds to fix per instance of these types of functions. SQL injection and mass assignment issues are far more serious threats than something like this, but they are not interesting because it's on the developer to secure their app. This issue is is built up to be serious because many people seem to enjoy attacking rai…

I agree that it's good that the vulnerability has a transparent framework level fix, and I myself would rather see 2-3 more framework level bugs than a whole new bug class like mass assignment. Bug classes are usually worse than bugs.

But that is not what people mean when they say this isn't a severe bug. They mean, "I read some article where some guy said you needed the right HMAC key on a cookie to exploit the bug", and I think that article is wrong, and thus the assertion about severity is wrong.

It is a severe bug with an easy fix. Unfortunately I think there are some other bugs orbiting around it that don't yet have fixes.

Post reply on HN