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

11–20 of 220 posts

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

#11

Post by dmix »

danso wrote: post #2

FWIW, this is the third time in seven months that Rails had to issue a patch related to how ActiveRecord handles method parameters. 3.2.6 (June 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... 3.2.4 (May 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

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.

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

#13

Post by charliesome »

codewright wrote: post #8
jtchang wrote: post #5

I am mostly a Django programmer so excuse my ignorance of rails. How does this keep happening? In Django you would do: Post.objects.get(pk=request.GET['id']) There really is no way to do SQL injection this way. This line in rails looks almost exactly like how you would do it in Django: Post.find_by_id(params[:id]) Also this seems really serious. It's not like a edge case where you need to grab a post by id. This is p…

Btw, this applies for my (Python) Flask apps using MongoDB ORMs. They escape the inputs. What the hell is going on with ActiveRecord?

The main issue stems from Ruby using the last positional parameter to pass a hash representing keyword arguments.

This means if there's only one parameter, and someone can sneak a Hash in there where you weren't expecting it (params parsing, request body parsing, etc) then they can end up passing dodgy 'keyword arguments' into your method call.

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

#14

Post by clamstar »

You need the contents of secret_token.rb to exploit this (via a forged session). This makes it much more of a danger to OSS projects than to those in the closed source space.

It's not just a SQL Injection vulnerability. With that secret token, you can set any session value you like.

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

#15

Post by danso »

jtchang wrote: post #5

I am mostly a Django programmer so excuse my ignorance of rails. How does this keep happening? In Django you would do: Post.objects.get(pk=request.GET['id']) There really is no way to do SQL injection this way. This line in rails looks almost exactly like how you would do it in Django: Post.find_by_id(params[:id]) Also this seems really serious. It's not like a edge case where you need to grab a post by id. This is p…

Rails does escape inputs with its finder and scope methods. I think the problem is that the "magic" in these methods allow for some edge cases to be parsed in unexpected ways...for example, when params[:id] contains a nested hash instead of a string or integer.

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

#16

Post by webjprgm »

This isn't a problem if you check the type of data you get from a user before you use it. You should be doing that anyway.

The article says a work-around is to use .to_s or .to_i on user input. My standard practice is to cast to int for all IDs I get externally (in PHP too). Some projects I work on go so far as to validate type and data ranges of every argument passed in. Those applications would therefore not be vulnerable even though Rails itself is.

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

#17

Post by jroes »

clamstar wrote: post #14

You need the contents of secret_token.rb to exploit this (via a forged session). This makes it much more of a danger to OSS projects than to those in the closed source space. It's not just a SQL Injection vulnerability. With that secret token, you can set any session value you like.

This is how I understand the issue as well. Many people in this thread are commenting about massive dangers, but I don't think anyone has bothered to actually read the references in the CVE.

Also, even open source projects typically ensure or recommend that the secret token be regenerated when using in production environments.

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

#18

Post by oomkiller »

It seems like this is being conflated with the session token issue? How do you submit params with symbolized keys? Hashes are easy enough, but it doesn't work with hashes that have strings as keys, only symbols.

EDIT: Just to be clear, tenderlove (Ruby/Rails committer) confirms that you do not need to edit the session to exploit this (http://news.ycombinator.com/item?id=4999767). It's still unclear how it is possible otherwise though, I assume he's being purposefully vague.

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

#19

Post by rst »

clamstar wrote: post #14

You need the contents of secret_token.rb to exploit this (via a forged session). This makes it much more of a danger to OSS projects than to those in the closed source space. It's not just a SQL Injection vulnerability. With that secret token, you can set any session value you like.

Different vuln; this one has nothing to do with session cookies.

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

#20

Post by biot »

dmix wrote: post #11
danso wrote: post #2

FWIW, this is the third time in seven months that Rails had to issue a patch related to how ActiveRecord handles method parameters. 3.2.6 (June 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... 3.2.4 (May 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

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 false dichotomy. I'd prefer to have people constantly test something for security vulnerabilities and find nothing because the code was thoroughly audited and shown to be secure before it was released.
Post reply on HN