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

71–80 of 220 posts

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

#71

Post by numbsafari »

plaguuuuuu wrote: post #59
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. This is still, mathematically-speaking, a bug. The function is supposed to find a post by ID. If its implementation causes side effects or returns unexpected results for a certain subset of possible input data, then it doesn't conform to spec. This…

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 whit, if you look at the bug report it says that the problem is when an application is passing user-provided data into the framework. They say "don't do that" and then apparently provide a patch to somehow get around if you don't (I don't know enough about the internals of rails to understand the patch).

To my mind, the problem is that Rails should be treating any data passed to it as user-provided data, rather than trusting somebody who just took a 21-day "hacker college" class to do anything other than just pass along user-provided data. The framework should be implementing this kind of security in a consistent and reliable way, rather than trusting you. That's kinda what a framework is for.

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

#73

Post by ultimoo »

Yahivin wrote: post #57
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…

The standard way to find a post in Rails would be: Post.find(params[:id]) That method is unaffected. The methods that are affected by this are the dynamic finder methods `find_by_*` such as: Post.find_by_id(params[:id]) This would most commonly occur when looking up users by a token or some other piece of data other than the id. User.find_by_token(params[:token]) I'm not sure why they chose to use find_by_id in the e…

True, but :find_by_id is closer to :where in that it doesn't raise exceptions upon not finding a record. I've seen it being used in a few places, especially in front another scope, like `current_user.posts.find_by_id`.

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

#74

Post by xentronium »

mnarayan01 wrote: post #58
latortuga wrote: post #26

Earlier quoted context omitted.

Rails param parsing automatically converts all param keys to symbols.

Just to expand on what others have already said...Rails converts params to http://api.rubyonrails.org/classes/ActiveSupport/HashWithInd... which means that `params[:foo]` and `params["foo"]` will both return the same thing. The function [`assert_valid_keys`]( http://api.rubyonrails.org/classes/Hash.html#method-i-assert... ), which is called in [`apply_finder_options`]( http://api.rubyonrails.org/classes/ActiveRecord/…

To expand on your expansion: when a hash with indifferent access is asserted over a list of symbols (as is the keys) it will always fail.

    1.9.3p327 :025 > {:a => "b"}.with_indifferent_access.assert_valid_keys([:a])
    ArgumentError: Unknown key: a

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

#75

Post by alberth »

The irony of this security vulnerability being announced by 37signals on Google Groups on the same day they release a new product called Basecamp Breeze [1] which is a direct competitor to Google Groups (and they compare it to Google Groups) ... hasn't gone unnoticed.

[1] http://basecamp.com/breeze/compare#google

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

#76

Post by amorphid »

hayksaakian wrote: post #66
danso wrote: post #62

Earlier quoted context omitted.

This is an ActiveRecord issue...MongoDB uses its own ORM (Mongoid/Mongomapper)

That's what I was referring to. Do mongomapper and mongoid have this problem?

On the bright side you need not fear this bug for your apps using MongoDB. Mongoid and MongoMapper do not use SQL, so there should be no SQL injection problems using those two options.

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

#77

Post by prodigal_erik »

numbsafari wrote: post #71
plaguuuuuu wrote: post #59

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 is still, mathematically-speaking, a bug. The function is supposed to find a post by ID. If its implementation causes side effects or returns unexpected results for a certain subset of possible input data, then it doesn't conform to spec. This…

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…

Not really a rubyist, but if you must do something as crazy as composing a query at runtime, isn't Object#tainted? the way to find out whether a string came from application code or from a user?

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

#78

Post by tenderlove »

charliesome wrote: post #61
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…

This is not the problem. Please stop spreading misinformation. ActiveRecord does escape user input. The exploit here is that under certain obscure circumstances it is possible trick ActiveRecord into thinking the user input is an options hash passed by the caller. From my understanding this is non-trivial to exploit on most applications, and requires passing in a Hash with symbol keys. This is still a vulnerability t…

Yes, it's true. You'd have to pass symbol keys. It's not easy to reproduce.

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

#79

Post by ClifReeder »

Yahivin wrote: post #57
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…

The standard way to find a post in Rails would be: Post.find(params[:id]) That method is unaffected. The methods that are affected by this are the dynamic finder methods `find_by_*` such as: Post.find_by_id(params[:id]) This would most commonly occur when looking up users by a token or some other piece of data other than the id. User.find_by_token(params[:token]) I'm not sure why they chose to use find_by_id in the e…

I believe if you do Post.find on a nonexistent id, a ActiveRecord::RecordNotFound exception is thrown, but this doesn't happen with the dynamically generated finders like find_by_id. Given this difference, it's possible you want to handle a missing record in a more graceful, non exception catching matter.

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

#80

Post by polemic »

numbsafari wrote: post #70
charliesome wrote: post #61

Earlier quoted context omitted.

This is not the problem. Please stop spreading misinformation. ActiveRecord does escape user input. The exploit here is that under certain obscure circumstances it is possible trick ActiveRecord into thinking the user input is an options hash passed by the caller. From my understanding this is non-trivial to exploit on most applications, and requires passing in a Hash with symbol keys. This is still a vulnerability t…

Umm.. I didn't say that ActiveRecord doesn't escape user input. So, stop spreading misinformation about my post ;-) The fact of the matter is, whether its in some dark edge-case or not, user-provided data is being used to compose a SQL statement that is being passed to the server. Escaped or otherwise, that's a recipe for an injection attack.

This misses the point. The problem is not that unsafe SQL is produced it is that the method signature is not always what is expected by the user.

This isn't actually an SQL injection flaw.

Post reply on HN