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

31–40 of 220 posts

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

#31

Post by FuzzyDunlop »

It seems easy to blame the magic finders for this (because they seem magic), or ActiveRecord alone, but really the problem is that 'secure by default' can trick you into thinking the framework will do it all for you.

It probably will most, if not all, of the time for you. But the complexity of such things understandably means there will be obscure vulnerabilities that are hard to track down.

Sanitising -- and even validating -- your params at the controller level is a nice way to stop some of these problems before they reach your models.

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

#33

Post by oomkiller »

latortuga wrote: post #26
oomkiller wrote: post #18

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

Rails param parsing automatically converts all param keys to symbols.

If I submit a form where the param is "login[select]=* from users limit 1 --" when I inspect params[:login] I get {"select"=>"* from users limit 1 --"}. Is there a different way of submitting things that converts it to symbols? params[:login] works due to it being a HashWithIndifferentAccess

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

#34

Post by codewright »

charliesome wrote: post #13
codewright wrote: post #8

Earlier quoted context omitted.

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.

You can pass a hash (dictionary) to represent kwargs in Python.

This seems like bad engineering fundamentals in the design of ActiveRecord for it to be perpetually subject to this sort of thing.

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

#35

Post by colinsidoti »

webjprgm wrote: post #16

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

"You should be doing that anyway."

A huge selling point of Rails, other web frameworks, and ORMs in general, is that you don't have to be doing these checks. You can push the query through without concern of SQL injection, and handle the failure case there. This is convenient because you often have to handle that failure case anyway.

Rails' own "Getting Started" guide uses this technique because it's assumed to be secure: http://guides.rubyonrails.org/getting_started.html#showing-a...

We know you can "break" the application by tampering with IDs, but you shouldn't be able to pose a security threat.

Validating type and data ranges is common with things like dropdowns, where you need to ensure an actual option was selected. This is a very common security flaw, and it's definitely good practice to be checking (especially when it leads to adding/updating database rows).

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

#37

Post by revelation »

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.

SQL injection is the web-equivalent of having a stack allocated buffer overflow. We have built and use (expensive) abstractions that supposedly eliminate these whole class of issues.

With Rails, you get the expensive abstraction and apparently none of the security.

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

#39

Post by bonzoesc »

danso wrote: post #9
zacksjoden wrote: post #6

For someone just learning RoR and having installed it via http://railsinstaller.org/ , how should I upgrade?

It should be as easy as 'gem update rails' at your command line (Terminal window). If you're just learning and creating an app for your own edification, this is not really an issue that will affect you. That is, it doesn't affect how you construct the app, so if for some reason the gem update process doesn't work, you won't be hindered from using RoR.

This won't work. The old version won't be purged, and it'll still be referenced in the Gemfile.

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

#40

Post by bonzoesc »

cheald wrote: post #7
zacksjoden wrote: post #6

For someone just learning RoR and having installed it via http://railsinstaller.org/ , how should I upgrade?

Run "bundle update rails" in your project's root directory (where your Gemfile is).

This won't work if your Gemfile declares a version of Rails (Rails 3.2.9 did this). You have to update the Gemfile and then bundle update.
Post reply on HN