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

161–170 of 220 posts

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

#161

Post by sontek »

jeltz wrote: post #144
untog wrote: post #127

Earlier quoted context omitted.

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.

http://sqlalchemy.org/ is an ORM and does not have these security issues. So it can be done.

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

#162

Post by [deleted] »

paulgb wrote: post #153
up_and_up wrote: post #143

Earlier quoted context omitted.

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

354 matches. https://github.com/search?utf8=%E2%9C%93&q=secret_token....

[deleted]

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

#163

Post by cheald »

tptacek wrote: post #128
cheald wrote: post #69

Earlier quoted context omitted.

I'm pretty sure that the injection only works when you can forge a session because sessions may contain marshalled symbols, and the dynamic finders only accepted symbol option keys as valid. You can't get Rails to construct symbols out of a params hash. Is this a separate vulnerability?

You can get Rails to construct symbols out of a params hash in some cases.

Seconding icambron - how? Because I've been up and down that code and can't see any way to do it. Frankly, I don't think it's possible, because otherwise you would have a trivial DOS vector into any Rails application.

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

#164

Post by kill9 »

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…

Yes, this page has a real torches-and-pitchforks feel to it. It's quite absurd.

The howls of derision from people who flat out say they don't even use the framework and clearly don't understand the vulnerability are particularly ridiculous.

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

#165

Post by RyJones »

josh2600 wrote: post #115
tptacek wrote: post #44

Earlier quoted context omitted.

Blue boxing predates 5ESS switches; 5ESS was notoriously the switch you couldn't blue-box.

Oh really? I always thought SS7 was the first switch to move to out of band. What's the last blueBox-able switch?

SS7 isn't a switch, it's an inter-switch OOB protocol.

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

#166

Post by kill9 »

icambron wrote: post #140
tptacek wrote: post #128

Earlier quoted context omitted.

You can get Rails to construct symbols out of a params hash in some cases.

Honest question: how?

I doubt tptacek will publicly reveal ways to exploit this (or any) vulnerability.

EDIT Well... he might, but I've never seen him do it. He's a security professional, after all.

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

#167

Post by RegEx »

eclipxe wrote: post #156
RegEx wrote: post #89

Earlier quoted context omitted.

nonexistent does not necessarily imply invalid. I don't use rails, so take my ignorance into account, but I'd hate to catch exceptions all the time instead of just checking for falsey values. Ex: "Enter your student ID" s = Student.find_by_id(params[:id]) if s # do stuff else # do other stuff end vs begin s = Student.find_by_id(params[:id]) # do stuff rescue # do other stuff end

This is a good example, however I would argue that it is bad design to have a record's ID used for user facing lookups. For other parameters, sure (find_by_name, etc) a false would be okay. Just a matter of taste really.

No argument here, good point.

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

#168

Post by steveklabnik »

ssmoot wrote: post #81
dmix wrote: post #11

Earlier quoted context omitted.

I've always found Rails to be easy to secure compared to most other frameworks. I think the defaults are all pretty secure. I'd prefer having constant security patches. It shows people are still constantly testing it for vulnerabilities.

That's a leap. Yehuda and I knew about the mass-assignment vulnerability during DataMapper v0.3, way back in the Merb days, before Rails3. Yet it didn't get addressed until a few months ago. PS: It's still broken IMO. It needed a rethinking of strategy and purpose. Instead it got a quick hack. If you want to see mass-assignment done right, look to Play Framework's First Class Forms support.

Mass assignment as a feature is completely removed from Rails 4, and a gem with the replacement (strong_parameters) is available _today_ for you to use with any 3.x application.

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

#169

Post by ufo »

cheald wrote: post #163
tptacek wrote: post #128

Earlier quoted context omitted.

You can get Rails to construct symbols out of a params hash in some cases.

Seconding icambron - how? Because I've been up and down that code and can't see any way to do it. Frankly, I don't think it's possible, because otherwise you would have a trivial DOS vector into any Rails application.

How is this a DOS vector? Would passing a symbol instead of a string in the parameters cause the app to crash?

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

#170

Post by tptacek »

cheald wrote: post #163
tptacek wrote: post #128

Earlier quoted context omitted.

You can get Rails to construct symbols out of a params hash in some cases.

Seconding icambron - how? Because I've been up and down that code and can't see any way to do it. Frankly, I don't think it's possible, because otherwise you would have a trivial DOS vector into any Rails application.

It is possible, but not straightforwardly. There isn't a code path I know of that converts param keys to symbols.

(I wouldn't have said it was possible unless I had a curl line that did it, for what it's worth.)

Post reply on HN