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

SQL Injection Vulnerability in Ruby on Rails; affects all versions

groups.google.com

Post reply on HN
Print view View original

141–150 of 220 posts

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#141

Post by venus »

chrismsnz wrote: post #138
venus wrote: post #136

Earlier quoted context omitted.

Sure. Here is the exploit: https://github.com/binarylogic/authlogic/pull/341

That's a bug/exploit in Authlogic, a third party library for rails, not rails. However, that bug/exploit is based on the rails vuln and was patched in authlogic exactly how the Rails report instructed people to work around it (casting the parameter to a string). Reading the actual report linked in the OP you'll see that generic and boilerplate code (e.g. the extremely common pattern: "Post.find_by_id(params[:id])") i…

The linked pull request described a method for getting unescaped code into the application so the issue with find_by_id might be exploited.

Have you got another way of getting unescaped code into the application such that this issue might be exploited? If so, the core team will be very, very interested to hear from you.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#142

Post by chrismsnz »

tenderlove wrote: post #139
chrismsnz wrote: post #133

Earlier quoted context omitted.

Please provide a source for your claims. From looking at it, it seems that ANY HTTP parameter (e.g. POST or GET - which are completely user-controlled) can be manipulated if you know how it's going to be used in the code, e.g. an obvious object ID. EDIT: tenderlove sets it straight below

You need a way to inject symbols as hash keys. Normal parameter handling does not allow this, so you need a different way to exploit the bug. As venus says, session forging is one way. Regular parameter handling is not.

I will defer to the rails core dev here :)

The linked vuln report gives the impression that regular parameter handling is vulnerable.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#143

Post by up_and_up »

chrismsnz wrote: post #138
venus wrote: post #136

Earlier quoted context omitted.

Sure. Here is the exploit: https://github.com/binarylogic/authlogic/pull/341

That's a bug/exploit in Authlogic, a third party library for rails, not rails. However, that bug/exploit is based on the rails vuln and was patched in authlogic exactly how the Rails report instructed people to work around it (casting the parameter to a string). Reading the actual report linked in the OP you'll see that generic and boilerplate code (e.g. the extremely common pattern: "Post.find_by_id(params[:id])") i…

"This leaves persist_by_session open to sql attacks (such as logging in as any user), if a malicious user can write their own rails session cookie (if they have the rails secret_token)."

The key is: "if they have the rails secret_token"

The secret token is autogenerated when the application is initially bootstrapped. Here is more information about it from any config/initializers/secret_token.rb file:

# Your secret key for verifying the integrity of signed cookies.

# If you change this key, all old signed cookies will become invalid!

# Make sure the secret is at least 30 characters and all random,

# no regular words or you'll be exposed to dictionary attacks.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#144

Post by jeltz »

untog wrote: post #127
qxcv wrote: post #123

Earlier quoted context omitted.

They do, but what we're talking about here is an ORM, so there will always be machine generated SQL somewhere. Or do you believe that GP is suggesting that developers use parameterised SQL queries instead of an ORM?

Er, why can't the ORM use paramaterised queries?

The problem is that ORMs like ActiveRecord really are just domain specific languages for building queries. If these DSLs use inband are carelessly constructed (e.g. they use some form of inband signaling) you can do the injection attack against the actual ORM code and make it build queries the author of the code did not intend.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#145

Post by jtchang »

venus wrote: post #132

The overreaction on this page is ridiculous. Has anyone actually read the steps required to exploit this vulnerability? You do know that to be able to exploit it you have to know the application's secret key, so you can create your own malicious encrypted session cookie that includes hashes instead of strings for the auth token lookup? You do know that if someone has your app's secret key they can just write whatever…

It is not an overreaction.

This is a much more subtle SQL injection.

I believe the takeaway is that too much magic is a bad thing when it obscures the underlying behavior.

Post.find_by_id( ) accepts an argument. Here are some normal assumptions:

1. It might only take a number

2. The method might coerce it to a string or integer for you

3. The method might not coerce it.

4. The method might throw an error if it isn't an int or the object isn't found.

5. The parameter is treated like a hash and used for lookups.

This last one seems a bit too much magic to me. I wouldn't even guess that last one as normal, expected behavior.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#146

Post by spamizbad »

numbsafari wrote: post #96
phillmv wrote: post #87

Earlier quoted context omitted.

>The fact that this keeps happening on Rails is the #1 reason I haven't bothered to take the time to do anything real with it. I don't have the time to read the code for the framework and I don't trust that it's written with security in mind. What frameworks do you use? Have you performed your own audit?

Totally fair question. I personally prefer not to use ORMs for this specific reason: they are typically way too complicated to be able to plow through the code in any reasonable way. It's also generally not that hard to design your application in such a way that using a minimalist "ORM-ish" layer of your own making isn't exactly a waste of time. I've also found that they rarely follow these best practices (it's madde…

Totally reasonable post. Sad to see it greyed out.

After years of working in ORMs I've come around to your thinking for bigger projects. ORMs are great, but they are large, complex, and sometimes opaque project dependencies and therefor should be employed sparingly. Parameterized SQL isn't that tough to write (and Python makes it easy) and often faster. The biggest drawback: it requires a dev team comfortable with SQL or the NoSQL library bindings you're using.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#147

Post by numbsafari »

rapind wrote: post #98
numbsafari wrote: post #71

Earlier quoted context omitted.

I didn't say it wasn't a bug. It's a bug that indicates that ActiveRecord was written/designed in such a way that it trusts user-provided data to be executed. And, yes, I would fully expect to be able to trust my data-abstraction layer to be bug free. Since Rails seems to have this problem regularly, I can't trust it and therefore choose not to use it for those purposes. So, I think we agree here. --- Edit --- To whi…

While I sort of agree with your argument, I question whether or not it's our responsibility to protect the world from the 21-day "hacker college" crowd. I would welcome throwing an error instead however. There needs to be some sort of expertise cutoff and I think it's reasonable to expect in a web framework that it's user's are informed enough to avoid these sort of mistakes. Eventually the scissors become so safe th…

I don't think we disagree. Developers should know about these issues and no framework will ever truly protect you from these kinds of mistakes. The question is, I think, is ActiveRecord an ORM that properly mitigates these issues.

Anecdotally, it seems to have recurring problems with SQL injection.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#150

Post by numbsafari »

jrochkind1 wrote: post #103
numbsafari wrote: post #47

Earlier quoted context omitted.

You are going to have problems with this whenever you are composing SQL statement with any type of user-provided data as part of the raw SQL string passed to the server. This generally happens in one of two says: 1) (most common) You have a SQL statement that takes a user-provided parameter and you compose your SQL statement as a string, including that parameter (eg., sql = "SELECT * FROM person where id = " + form.i…

> You are going to have problems with this whenever you are composing SQL statement with any type of user-provided data as part of the raw SQL string passed to the server. True, but Rails is not doing that, was never doing that, and the patch has nothing to do with this. So you're talking about something unrelated to this security flaw.

I'm confused. If it's not doing that, and was never doing that, then how does an HTTP cookie's value end up injected into a SQL statement generated by Rails?
Post reply on HN