SQL Injection Vulnerability in Ruby on Rails; affects all versions

Post by sandstrom » Wed, Jan 02, 2013, 10:42 PM UTC

danso wrote: post #15

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.

Post by mnarayan01 » Wed, Jan 02, 2013, 10:44 PM UTC

oomkiller wrote: post #33

latortuga wrote: post #26

Earlier quoted context omitted.

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

Post by xentronium » Wed, Jan 02, 2013, 10:46 PM UTC

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…

    +  def test_find_by_id_with_hash
    +    assert_raises(ActiveRecord::StatementInvalid) do
    +      Post.find_by_id(:limit => 1)
    +    end
    +  end
    +
    +  def test_find_by_title_and_id_with_hash
    +    assert_raises(ActiveRecord::StatementInvalid) do
    +      Post.find_by_title_and_id('foo', :limit => 1)
    +    end
    +  end
    +

    1.9.3p327 :017 > Forum::Thread.find_by_id_and_forum_id(1, {:limit => 10}.with_indifferent_access)
    ArgumentError: Unknown key: limit
        [backtrace skipped]

Post by Yahivin » Wed, Jan 02, 2013, 10:50 PM UTC

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…

    Post.find(params[:id])

    Post.find_by_id(params[:id])

    User.find_by_token(params[:token])

Post by plaguuuuuu » Wed, Jan 02, 2013, 10:52 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…