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

91–100 of 220 posts

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

#91

Post by mikeash »

georgemcbay wrote: post #88
josh2600 wrote: post #30

Earlier quoted context omitted.

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.

Asking Jobs is pretty easy. It's getting an answer that's difficult.

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

#92

Post by benmmurphy »

Xylakant wrote: post #60
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…

Not everything that gets passed to the find_by_ methods has to come from the params hash. The sessions hash is another source of data that gets fed to such methods. See this PR https://github.com/binarylogic/authlogic/pull/341

if you can control session hash it may also be possible to execute arbitrary ruby code. if you take an object from the session hash and call a method on it then depending on the method name it is possible to eval arbitrary ruby code.

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

#94

Post by ojr »

VMG wrote: post #21
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.

by that logic php is rock solid

75% of web servers run on it, I think thats a pretty solid mark

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

#95

Post by xentronium »

MichaelGG wrote: post #90
xentronium wrote: post #65

Earlier quoted context omitted.

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.

There is slight benefit in readability for cases like find_by_name_and_role("Jack", "admin"), but other than that, no benefit whatsoever.

In Rails 4.0, most dynamic finders are deprecated and removed from the source into a separate gem.

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

#96

Post by numbsafari »

phillmv wrote: post #87
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…

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

Totally fair question.

I personally prefer not to use ORMs for this specific reason: they are typically way too complicated to be able to plow through the code in any reasonable way. It's also generally not that hard to design your application in such a way that using a minimalist "ORM-ish" layer of your own making isn't exactly a waste of time. I've also found that they rarely follow these best practices (it's maddening).

I have, however, had to make use of Hibernate, SQL Alchemy and Django's ORM on projects where I didn't make the calls. I'm pretty sure Hibernate uses parametric, prepared statements. I believe SQLAlchemy and Django ORM do not, but use their own escaping mechanism internally. In addition, I don't know about Hibernate and SQLA, but I'm pretty sure that Django's ORM API does make it possible to cause the framework to generate SQL using user-provided data for column/table names in a manner similar to ActiveRecord.

By way of contradicting myself, I do believe that ORMs are great for writing internal use-utilities that are one-offs or quick-and-dirty tools. In general, those cases preclude the use of autonomously provided user data for query building. For world-facing code, ORMs are risky unless you've got someone on the team who knows it and has the ability to ensure it doesn't suffer from these types of design flaws.

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

#97

Post by xentronium »

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?

If you want an exception, there is a banged version:

    # note the exclamation mark
    User.find_by_id!(id) # => raises exception when nothing is found

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

#98

Post by rapind »

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…

While I sort of agree with your argument, I question whether or not it's our responsibility to protect the world from the 21-day "hacker college" crowd. I would welcome throwing an error instead however.

There needs to be some sort of expertise cutoff and I think it's reasonable to expect in a web framework that it's user's are informed enough to avoid these sort of mistakes.

Eventually the scissors become so safe that you can't cut anything with them.

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

#99

Post by srdev »

phillmv wrote: post #86
revelation wrote: post #37

Earlier quoted context omitted.

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

Likely its an argument to use parameterized queries which fix the SQL injection problem altogether. I'm not familiar with Ruby, but surely they support it in 2013?
Post reply on HN