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

121–130 of 220 posts

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

#121

Post by benlower »

xentronium wrote: post #102
benlower wrote: post #12

So does the fact that "Rails is Omakase" ( http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... ) mean that the chef tried to serve Fugu ( http://en.wikipedia.org/wiki/Fugu ) but cut it wrong?

I think this is a correct analogy, but you have to take something else into consideration: there are no chefs that don't cut fugu wrong from time to time. We should cut fellow programmers some slack.

xentronium: i agree on cutting slack. my comment was mostly meant to be fun and to only poke a bit :-)

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

#122

Post by threedaymonk »

xentronium wrote: post #102
benlower wrote: post #12

So does the fact that "Rails is Omakase" ( http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... ) mean that the chef tried to serve Fugu ( http://en.wikipedia.org/wiki/Fugu ) but cut it wrong?

I think this is a correct analogy, but you have to take something else into consideration: there are no chefs that don't cut fugu wrong from time to time. We should cut fellow programmers some slack.

"there are no chefs that don't cut fugu wrong from time to time"

This doesn't seem to be the case: fugu preparation is licensed and regulated, and deaths are very rare indeed. I can't find exact numbers offhand, but according to a paper cited on Japanese Wikipedia, there were 315 fugu poisoning incidents in Japan in the 10 years from 1996 to 2005. Of those, 31 were fatal, and of those, the majority were due to preparation by unqualified individuals (presumably those who had caught fugu themselves).

Given the quantity of fugu consumed nationwide, it seems reasonable to say that, in fact, most chefs never cut fugu wrong - or at least that most chefs never serve wrongly cut fugu.

https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%B0#.E3.83.95.E...

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

#123

Post by qxcv »

srdev wrote: post #99
phillmv wrote: post #86

Earlier quoted context omitted.

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?

They do, but what we're talking about here is an ORM, so there will always be machine generated SQL somewhere. Or do you believe that GP is suggesting that developers use parameterised SQL queries instead of an ORM?

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

#125

Post by waffle_ss »

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.

No, it's a bit more elaborate than that. If what you said were strictly true you could DoS any Rails app as symbols are never garbage collected - you could just continue sending new param keys to the app until it runs out of memory.

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

#126

Post by xentronium »

threedaymonk wrote: post #122
xentronium wrote: post #102

Earlier quoted context omitted.

I think this is a correct analogy, but you have to take something else into consideration: there are no chefs that don't cut fugu wrong from time to time. We should cut fellow programmers some slack.

"there are no chefs that don't cut fugu wrong from time to time" This doesn't seem to be the case: fugu preparation is licensed and regulated, and deaths are very rare indeed. I can't find exact numbers offhand, but according to a paper cited on Japanese Wikipedia, there were 315 fugu poisoning incidents in Japan in the 10 years from 1996 to 2005. Of those, 31 were fatal, and of those, the majority were due to prepar…

That sentence referred to original post, read it as "there are no programmers that never make bugs". I didn't mean the real chefs!

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

#127

Post by untog »

qxcv wrote: post #123
srdev wrote: post #99

Earlier quoted context omitted.

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?

They do, but what we're talking about here is an ORM, so there will always be machine generated SQL somewhere. Or do you believe that GP is suggesting that developers use parameterised SQL queries instead of an ORM?

Er, why can't the ORM use paramaterised queries?

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

#128

Post by tptacek »

cheald wrote: post #69
tenderlove wrote: post #43

Earlier quoted context omitted.

Yes, the article does mention session secrets. However, this exploit does not require session secrets. The person who wrote the blog post wrote about essentially two vulnerabilities: session forging and SQL injection.

I'm pretty sure that the injection only works when you can forge a session because sessions may contain marshalled symbols, and the dynamic finders only accepted symbol option keys as valid. You can't get Rails to construct symbols out of a params hash. Is this a separate vulnerability?

You can get Rails to construct symbols out of a params hash in some cases.

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

#129

Post by [deleted] »

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.

[deleted]

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

#130

Post by numbsafari »

venus wrote: post #118
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.

> 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 How do you implement authentication if you can't check an email (user provided data) matches a password (user provided data, probably hashed but still)? How do you look up blog posts by a user-provided tag, without using that tag in query composition? How do y…

Simple: use parametric prepared statements instead of composing a SQL string with the user-provided data (escaped or otherwise).

This has been available in numerous database APIs for like, ever.

For example [1], [2], [3]. Any actual web developer will have read something along the lines of [4].

A lot people seem confused by my original post, which was in response to a Django user's question about how this sort of thing happens. I provided a general response which seems to have offended some people.

Yes, Rails does appear to use parameterized statements. However, when it is building those parameterized statements it's still using user provided data to build the SQL. If that weren't the case, then this wouldn't be a bug at all, would it? Of course not, so obviously it is using user-provided data in some way, otherwise an HTTP cookie's value wouldn't be getting passed to the database, would it? The prepared statement string shouldn't be composed with anything user provided.

[1] http://php.net/manual/en/mysqli-stmt.bind-param.php

[2] http://bit.ly/WlPEFR

[3] http://rubydoc.info/gems/mysql/2.9.0/Mysql/Stmt

[4] https://www.owasp.org/index.php/Top_10_2010-A1

Post reply on HN