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.

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

You're a ruby or obj-c coder, I assume?

An Objective-C coder would get an answer thanks to Objective-C's terrible nil semantics.

Blue boxing predates 5ESS switches; 5ESS was notoriously the switch you couldn't blue-box.

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/Phreaking/Phreak... ) says "Blue boxing becomes harder as all Bell switching and transmission facilities go under to CCIS. Then to further complicate things, digital microwave, fiber optic, and satellite transmission are all coming to be digital and do not recognize 2600hz for the hang up signal. I predict that around 1990, blue boxes will be obsolete from all major cities."

The 2600 FAQ, Section C-07, says (the earliest date I found for this was August 9, 1993): "Because of ESS Blue boxing is impossible". This is incorrect. ... While the advent of ESS (and other electronic switches) has made the blue boxers task a bit more difficult, ESS is not the reason most of you are unable to blue box. The main culprit is the "forward audio mute" feature of CCIS (out of band signalling). ... So for the clever amongst you, you must somehow get yourself to the 1000's of trunks out there that still utilize MF signalling but bypass/disable the CCIS audio mute problem.

I don't know the switch models enough to say if it was exactly 5ESS, but everything suggests that that is the case.

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

SS7 isn't a switch, it's an inter-switch OOB protocol.

No, 5ESS was the switch that used out-of-band signalling and was not susceptible to 2600 tricks.

Maybe you didn't get the memo about Steve Jobs?

This isn't an in-band signaling error, per se. This is not an issue of escaping the quotes or something, rather the way this issue works is that User.find_by_username(params[:username]) is interpreted wildly differently if params[:username] is a string compared to if it is a different data type. If it is not a string, then the "options" for the dynamic finder are automatically extracted. It turns out that you probably don't want to leave it up to your user to decide if that param should be a string or a more complex data type...

for instance, before this patch you could do User.find_by_username('whocares', :conditions=>"ARBITRARY SQL")

While the method itself may not be doing in-band signaling, the vulnerability is certainly very related. What was supposed to be strictly data, params[:username], actually becomes an in-band signal -- and that's the exploit.

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.

This is silly. The stinger on this vulnerability is SQL injection, but the vulnerability itself is closer in spirit to code injection. The issue here isn't database hygiene. Parameterized queries would not have helped.

There's a real critique of Rails to be leveled here (there is some fucked up stuff going on with Rails request processing), but yours isn't it.

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?

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

The problem is that ORMs like ActiveRecord really are just domain specific languages for building queries. If these DSLs use inband are carelessly constructed (e.g. they use some form of inband signaling) you can do the injection attack against the actual ORM code and make it build queries the author of the code did not intend.

http://sqlalchemy.org/ is an ORM and does not have these security issues. So it can be done.

Searching for "sqlalchemy sql injection" brings up this: https://bugzilla.redhat.com/show_bug.cgi?id=783305

I did not say otherwise. I said that ORMs may be vulnerable if they are carelessly constructed.

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.

Actually, no, not if you're using the mysql2 gem. There is an open issue / pull request but it doesn't seem to have much momentum.

https://github.com/brianmario/mysql2/pull/289

I am not sure I think of abstractions as featuring improved security. I recently did an (internal to client) blog post about the job of a penetration tester as "puncturer of abstractions". I do have permission to publish it publicly, so I plan to do so.

But briefly, if you think of a grammar such as HTML in terms of an abstraction, the very fact that you need to encode output when creating HTML indicates that the abstraction can be "punctured".

And many abstractions, such as stored procedures, don't help you out at all. There is a oft-repeated untruth that somehow stored procedures magically prevent SQLi.

That's a false dichotomy. I'd prefer to have people constantly test something for security vulnerabilities and find nothing because the code was thoroughly audited and shown to be secure before it was released.

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.

Mass assignment as a feature is completely removed from Rails 4, and a gem with the replacement (strong_parameters) is available _today_ for you to use with any 3.x application.

by that logic php is rock solid

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

Not when the 66% of them get 0wned