SQL Injection Vulnerability in Ruby on Rails; affects all versions • Hacker News Board

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

#81

Post by ssmoot » Wed, Jan 02, 2013, 11:25 PM UTC

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 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.

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

#82

Post by eclipxe » Wed, Jan 02, 2013, 11:27 PM UTC

ultimoo wrote: post #73

Yahivin wrote: post #57

Earlier quoted context omitted.

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`.

If you have an invalid id coming in, wouldn't you generally want an Exception? What is the use case where the app would send an id that does not exist, but you would not want to fail?

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

#83

Post by dholowiski » Wed, Jan 02, 2013, 11:29 PM UTC

Oh. I always figured it was bad coding, but I normally use the workaround anyway. Post.find_by_id(params[:id].to_s)

Regardless, I think I have some patching to do tonight.

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

#84

Post by hayksaakian » Wed, Jan 02, 2013, 11:34 PM UTC

amorphid wrote: post #76

hayksaakian wrote: post #66

Earlier quoted context omitted.

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.

I'm aware they don't use SQL, but someone on HN once told me there was some kind of JavaScript injection you could do in theory. Was wondering how mongoid would handle this technique.

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

#85

Post by numbsafari » Wed, Jan 02, 2013, 11:34 PM UTC

polemic wrote: post #80

numbsafari wrote: post #70

Earlier quoted context omitted.

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.

Um... have you read the linked posting?

>Carefully crafted requests can use the scope to inject >arbitrary SQL.

It's also titled "SQL Injection Vulnerability". Are we all missing something?

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

#86

Post by phillmv » Wed, Jan 02, 2013, 11:34 PM UTC

revelation wrote: post #37

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.

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.

Yes, clearly, because Rails has introduced absolutely no other kind of default protection.

Is this an argument for hand rolling your own code, or for using some other framework that is apparently immune (or, to be charitable, has a stronger security track record)?

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

#87

Post by phillmv » Wed, Jan 02, 2013, 11:36 PM UTC

numbsafari wrote: post #47

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…

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…

>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?

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

#88

Post by georgemcbay » Wed, Jan 02, 2013, 11:39 PM UTC

josh2600 wrote: post #30

charliesome wrote: post #25

Earlier quoted context omitted.

History seems to keep reminding us that in-band signalling is a convenient idea fraught with danger.

Look no further than the deprecated 5ESS switches which used to give up free calls due to 2600hz tones being signaled inband. Ask Steve Jobs and Woz about BlueBoxes; you need look no further to see the inherent dangers on inband signaling. Slightly off-topic, but still relevant IMHO.

Asking Steve Jobs a question is going to require a very impressive in-band signaling hack on a system that appears to have no such vulnerability.

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

#89

Post by RegEx » Wed, Jan 02, 2013, 11:41 PM UTC

eclipxe wrote: post #82

ultimoo wrote: post #73

Earlier quoted context omitted.

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`.

If you have an invalid id coming in, wouldn't you generally want an Exception? What is the use case where the app would send an id that does not exist, but you would not want to fail?

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

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

#90

Post by MichaelGG » Wed, Jan 02, 2013, 11:47 PM UTC

xentronium wrote: post #65

eranation wrote: post #24

Would appreciate if someone could explain the issue in a little more detail for non RoR developers

Assuming you have no ruby knowledge: ActiveRecord (rails' default ORM) has a feature called "dynamic finders". When you call a method like `Forum.find_by_url('news.ycombinator.org')` it gets a first forum with such url. This is a sugar over `Forum.where(:url => 'news.ycombinator.org').first`. Normally, you use it like that `Forum.find_by_url(params[:url])` where `params` is a hash of parameters (that is auto-generate…

What's the great benefit of these methods? Why not just do find_by("url", x)? I just don't understand the desire to move string parameters into member names.