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

211–220 of 220 posts

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

#211

Post by SilasX »

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…

Whoa whoa whoa, let's be fair. As a graduate of one of these "hacker colleges" that used RoR [1], and who was a hobbyist programmer long before it, these magically generated function names (and plurals, etc) scared the hell out of me.

In all my experience with programming, I had become accustomed to the mentality of "the compiler/interpreter expects identifiers to be exactly right; it doesn't figure out what you 'really' mean". So it was frustrating to see these auto-generated methods, as I couldn't see the rhyme or reason behind where these methods were coming from.

Fortunately, I found work at a Django shop, where the framework is so much easier to follow and more explicit about how it does things.

[1] devbootcamp.com, first cohort, Spring 2012, though it was actually more like 60 days with 40 days of instruction. I'm now employed as a developer and trusted with production code.

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

#213

Post by josh2600 »

dalke wrote: post #131
josh2600 wrote: post #115

Earlier quoted context omitted.

Oh really? I always thought SS7 was the first switch to move to out of band. What's the last blueBox-able switch?

Let's see. Phrack Volume Three, Issue 25 says "In March of 1982, the 5ESS switch first went into operation." Esquire published "Secrets of the Little Blue Box" in the October 1971 issue of Esquire, based on the phone system MF design from the 1950s/1960s. That means blue boxing started at least 15 years before 5ESS, as tptacek pointed out. The 1987 Phreakers Manual ( http://fringe.davesource.com/Fringe/Hacking/Phreak…

Thanks for the wonderfully educational comment :). I sincerely appreciate it!

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

#214

Post by trainspottin »

numbsafari wrote: post #85
polemic wrote: post #80

Earlier quoted context omitted.

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?

um um um you sound like an idiot. shut up already you've failed to redeem and save face.

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

#215

Post by numbsafari »

j-kidd wrote: post #207
numbsafari wrote: post #96

Earlier quoted context omitted.

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 madde…

> I'm pretty sure Hibernate uses parametric, prepared statements. I believe SQLAlchemy and Django ORM do not, but use their own escaping mechanism internally. You have no credibility to talk about database if you can't tell what kind of statements are being executed.

Um... it's been about a year since I sat around looking at the output of any of those three libraries and it wasn't worth the effort to go back and fire something up to be "certain". So I used the appropriate words "I believe" and "I'm pretty sure" to indicate that I was make statements based upon the recollections of my frail human memory ... also, those libraries are actively developed (last I checked) and could have changed since I last used them.

You have no credibility to talk about my credibility if you read too much into every single sentence I write without context.

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

#216

Post by numbsafari »

phillmv wrote: post #186
numbsafari wrote: post #96

Earlier quoted context omitted.

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 madde…

I think this kind of view point is mostly influenced by having to deal with poorly designed ORMs and (tho occasionally very necessary) convoluted database designs. > 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. This I think is wrong, for the same reason you don't want to be putting together yo…

I think you're making a valid criticism of my position. That said, I don't know that I would (personally) put SQL calls in the same boat as crypto. Crypto involves a lot of complex math and code that, if off by a single bit can wreck the whole house of cards.

In general, I think the problem that ORMs face is that they try and match every single problem thrown at them. People criticize your ORM saying "it doesn't handle egde case XYZ in my legacy data model" or "it suffers from this performance problem when somebody puts a tire boot on the server". Rather than saying "don't use an ORM to solve your unpaid parking ticket problem", the ORM team will devise a way of providing multiple method signatures in a language that loosely supports the feature so that unpaid parking tickets will always be paid prior to the server getting a boot.

Eventually the support for all these edge cases adds up to a very complex piece of software that, to your point, rivals the complexity and fragility of crypto code.

To me... it's more about saying "I have a limited set of use cases here, I don't need a leatherman to cut this noose around my neck I just need a steak knife". ActiveRecord is an impressive freaking tool and I don't begrudge anyone for using. If you ship working code using it then it did it's job.

My personal taste is to stick with simpler tools that don't have so many edge cases so I can sleep easier at night.

Suffice it to say, where you draw the line on "too complex for my taste" and where I would draw that line is probably different and the result of both our personal experiences as well as the problems we are trying to solve.

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

#217

Post by numbsafari »

trainspottin wrote: post #214
numbsafari wrote: post #85

Earlier quoted context omitted.

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?

um um um you sound like an idiot. shut up already you've failed to redeem and save face.

You're the one calling people names. The guy who wrote the fix that was actually accepted by the Rails core team called this a "SQL Injection" and it has been filed in that category by numerous independent bug trackers.

I don't quite understand the angst about this defect being called a SQL injection vulnerability. The vector for the attack doesn't change the end result.

The cause might be that the API was broken, but it doesn't change the fact that a guy wrote SQL code that was injected into the middle of the rest of the SQL generated by the ORM.

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

#218

Post by numbsafari »

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?

NB: what I'm about to write isn't specific to ActiveRecord, it's about SQL injection in general. So please, don't read this thinking I'm making specific claims about AR. I'm just responding to one part of the above claim.

Anyhow...

Parameterized queries do not "fix the SQL injection problem altogether". They solve the most common issue where someone is simply building up a full SQL statement and passing user inputs as part of the string (not as parameters). I call that "Class 1" SQL injection problem. You find this a lot in hand-rolled web apps (especially PHP apps since the legacy MySQL library hasn't been snipped out yet and most tutorials explicitly tell you to do this, even though PHP has long supported parametric SQL).

However, many DB access libraries and ORMs offer facilities that generally revolve around the desire to allow the client application to customize or optimize the generated SQL created by the library (or bypass the SQL generation but leverage the library managed connection state). The API typically just trusts that you know what you are doing, blindly accepts the SQL you give it and injects it into (or replaces) whatever it generated on its own. These are the source of what I call those Class 2 injection vulnerabilities. That is, SQL gets injected in what cannot otherwise be parameterized. These can be mitigated by running a sanity check on the full SQL before it goes to the server (for example, searching it for comment strings and raising and exception or returning an error if they are detected). They can also be detected by scanning your query logs for the same things. Also, this is typically caused by a bug in your code, not the library, since it was trusting you to give it clean SQL.

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

#219

Post by numbsafari »

cdcarter wrote: post #187
numbsafari wrote: post #130

Earlier quoted context omitted.

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 thi…

The attack is targeting a secondary method signature that #find_by_* can hold with the express purpose of executing arbitrary SQL. That is, when #find_by_* is invoked with a hash with a key such as :select or :conditions it expects a SQL string, probably hard coded. The bug however is that it's possible for user input, with a session hijacking, to provide that hash with symbolic key. There is no SQL injection, this i…

Out of curiosity, all other debates aside, would it not be helpful to have (either built-in or as a separate plugin) a way for Rails to run a simple set of sanity checks on the SQL it passes to the DB server? For example, checking to make sure that the generated SQL doesn't contain "--" wouldn't fix the underlying problem, but it could be used to prevent the exploit from ultimately working (and, if someone tried this, would alert you to that fact, assuming the error was logged).

I get that this would create some performance overhead, so it would ideally be configurable.

Post reply on HN