[tptacek]

It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue.

The examples you've provided of Rails SQLI issues are bad ones:

* The first is a discussion of SQLI in an interface designed to accept raw SQL; it's the ActiveRecord "back door" interface.

* The second is a discussion of SQLI in a context where parameterized queries don't work anyways (the MySQL protocol doesn't accept LIMIT and OFFSET arguments as anything but integer constants); it is also the simplest of the class of SQLI concern areas (you can solve it by blindly calling #to_i on your inputs), which also includes table names, sort orders, and column references.

[nupark]

It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue.

The database is the normative reference on what is and is not a special cased character and how escaping should be implemented. I don't think it's reasonable to assert that escaping is a concern that should be adopted by every framework that might ever talk to a database.

The examples you've provided of Rails SQLI issues are bad ones

I'm sure you could supply some better examples since your focus is in security, and there are a vast number of issues that have arisen in ActiveRecord's escaping (especially in early versions of Rails). These are merely what I quickly found while Googling.

The first is a discussion of SQLI in an interface designed to accept raw SQL; it's the ActiveRecord "back door" interface.

It's also an interface that was repeatedly and unintentionally used by Rails users to insert unescaped queries in a way that did not immediately appear incorrect, as evidenced by the preponderance of questions on the subject.

The second is a discussion of SQLI in a context where parameterized queries don't work anyways (the MySQL protocol doesn't accept LIMIT and OFFSET arguments as anything but integer constants); it is also the simplest of the class of SQLI concern areas (you can solve it by blindly calling #to_i on your inputs), which also includes table names, sort orders, and column references.

Given that this conversation is occurring in the context of discussing how MySQL's design has led to exactly these types of errors, I think this is an applicable example.

[tptacek]

A "vast number of issues"? Huh? Citation needed.

I don't know how to respond to any of these points.

The discussion at hand is, "who's job is it to defend against SQLI, the database, the framework, or the application?".

Of those three components, the database is least well equipped to defend against SQLI. SQLI is "avenue for attacker to submit queries to a database contrary to the intentions of the application". The database's simple job is to accept and execute queries.

[nupark]

A "vast number of issues"? Huh? Citation needed.

The last time I researched this, I started here:

http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3...

... would up and sources like this:

http://lists.rubyonrails.org/pipermail/rails/2004-December/0...

... and spent a good hour reading the Rails source code. My take away was that, historically, a lack of care coupled with a lack of use of the parameterized APIs left the door open to repeated failures in the implementation to protect against SQL injection.

Things have improved in Rails, but as a historical example of the pitfalls of ignoring/eschewing parameterized query APIs, I believe it to be quite valid.

The discussion at hand is, "who's job is it to defend against SQLI, the database, the framework, or the application?". Of those three components, the database is least well equipped to defend against SQLI. SQLI is "avenue for attacker to submit queries to a database contrary to the intentions of the application". The database's simple job is to accept and execute queries.

No, you're reframing the discussion. The original poster commented on MySQL's longtime begrudging support for parameterized queries (or lack thereof) as one of the major causes of the prevalence of SQL injection issues.

It seems clear to me that the database -- as the central implementation responsible for parsing queries -- is the best equipped to provide safe, correct string interpolation of those queries.

[tptacek]

People that don't know Rails are going to think that you're making pointed critiques of the framework, when in fact you appear to be repeatedly citing examples of people going through extra effort to use the interfaces Rails provides for directly using SQL instead of ActiveRecord's finders.

[nupark]

I'm not offering a "pointed critique of Rails" ([edit] although your framing it as such seems to encourage downvotes into the negatives). I'm demonstrating how the use of non-parameterized queries source of error that has repeatedly resulted in SQL injection issues in ActiveRecord. I have provided three different examples:

- In the first, the API design itself made it non-obvious/easy to directly concatenate strings while -- at a glance -- appearing to be correct.

- In the second, the API's implementation resulted in SQL injection because :limit and :offset arguments were not correctly escaped.

- In the third, the API's documentation and recommended usage (in 2004) encouraged users to use constructs that appeared to provide defense against SQL injection, but in reality, did not.

[awj]

> It is not unreasonable to assert that SQLI defense is a framework concern, not a database issue.

Sure, but it is unreasonable to assert that SQLI defense is not also a database issue.

Using the provided apis in a way that prevents SQLI is a framework concern. Providing apis that make that possible without re-implementing basic things like escaping is a database concern, otherwise you're just asking people to re-solve the same problems so they each get a chance to screw it up.

[tptacek]

SQL defense isn't a database issue.

The SQL Injection vulnerability is, "user coerces application into submitting an unexpected and unauthorized query".

Blaming the database for that is like blaming the filesystem for pathname injection vulnerabilities.

It could, after all, send a Unix signal to a calling process when a filename contained "..", and demand that the process re-assert it's desire to really reference a different directory.

We may be spiraling here. Parameterized queries are a good thing. I'm glad MySQL has them. I'm not, however, going to wag a finger at MySQL every time someone finds an SQLI vulnerability in an app that uses MySQL, just because 6-7 years ago they didn't have parameterized queries. For one thing, it's not a useful comment (do you want them to implement parameterized queries... again?); for another, it's not particularly valid architectural point; and finally, it's really boring.

[awj]

I think we definitely are spiraling. My argument is about how the stance MySQL took on parameterized queries has affected the product's community. I don't disagree with you on the technical issues. Well, except that providing useful tools to handle SQL defense correctly is a database issue. And pathnames are a read herring, as they are not a transport for data manipulation commands.

I guess part of it is that I'm just done watching various problems with MySQL (transaction support, parameterized queries, subqueries, bizarro query optimization) be given a pass as "not quite MySQL's problem". Maybe I'm just taking that out on this thread.

[zwp]

> you can solve it by blindly calling #to_i on your inputs

"You can solve it by blindly calling #h on your outputs"

Ouch. We know that scheme doesn't work too well: it's why we had #h and we now have #html_safe...

[tptacek]

Not comparable. h() was a one-sized-fits-all problem to quoting things that could occur anywhere in an HTML DOM. #to_i assures that a bit of syntax that can only ever accept integers is in fact given a real integer.

In case we're misunderstanding each other, I'm also saying that the framework should be doing that, not the caller (as was the case with h()).

[zwp]

Thanks, yes misunderstanding: agree should be a framework protection not something developer should be sprinkling over code.