I have never heard someone say parameterized queries were "useless enterprise bloat". Their use in modern web apps is an industry best practice widely adopted across all the Internet apps Matasano gets to test. Your reaction here sounds hyperbolic, and the parent commenter is right: parameterized queries, while helpful, are neither required nor sufficient for defense against SQLI.

> I have never heard someone say parameterized queries were "useless enterprise bloat".

I have. Usually from people with no idea what they're talking about, maybe one of us has been (un)lucky in our experience. Hopefully it's me.

> Their use in modern web apps is an industry best practice widely adopted across all the Internet apps Matasano gets to test.

That's great! How long has it been true, though? When I first learned PHP (2003), this was not mentioned. Maybe it existed, either in MySQL directly or as an api method, but it certainly wasn't widely advertised. Maybe looking all the way back to 2003 is stepping outside the scope of "modern" here, but I still occasionally get to deal with problems created back then.

> Your reaction here sounds hyperbolic, and the parent commenter is right: parameterized queries, while helpful, are neither required nor sufficient for defense against SQLI.

I'm sure it does, considering the differences in our experience of the situation.

Also, my point was not that parameterized queries are the end of SQLI defense or required for it. Just that you can't give MySQL as a company a pass on a situation they helped create. Parameterized queries are a very simple and common first step in learning to deal with SQL injection. Not implementing them for so long did not help the situation in this respect.

Could you expand a bit on how parameterized queries are not sufficient for defense against SQL injection (assuming, of course, that developers use the escaping and do not concatenate unescaped data into queries)?

As for them being required -- you can obviously escape queries yourself, but the normative reference for escaping is the target database itself, and reproducing escaping locally in the client brings with it the likelihood of introducing an error in the custom implementation.

Not every "input" to a "query" (using these terms loosely) can be bound as a variable. Simple example: ASC and DESC. There are trickier examples that are still common.

It is a bad idea for applications to implement quoting regimes, and it is a bad idea for frameworks to try to create one-size-fits-all quoting regimes like PHP used to. That doesn't mean it's a bad idea for a framework's e.g. MySQL support to provide the capability of sanitizing MySQL inputs under a common database API.

The problem with that is that almost nobody uses the official database APIs. The official APIs are usually C libraries (e.g. libmysqlclient) but pretty much everybody uses third party wrappers (e.g. Perl DBI, the mysql/mysql2 gem for Ruby, the PHP default MySQL bindings, etc). Few people program against the database in C or C++. It was and is up to the third party API providers to provide easy sanitization APIs, I don't see how MySQL could have changed that situation by providing such APIs themselves.

> Their use in modern web apps is an industry best practice widely adopted across all the Internet apps Matasano gets to test

I'll resist the pot/kettle/colour connection here about plugging your own stuff on HN in a web app security thread. Agh, too late.

On a more serious note, if all the Internet apps Matasano test are using parameterized queries then:

a) Matasano never tests a MySQL-based app

AND

i) Matasano does very little web app testing these days

OR

ii) You're not quite telling us the truth

Seriously, parameterized queries while being a best practice so to speak are not a one size fits all solution and is not something implemented by everyone. The amount of shonky development practices we come across at my unnamed and unplugged company far outweighs the instances of the security aware, certainly on the first, second and sometimes third time round.

Today I'm testing a wordpress-based web app. A beer says that it's not using parameterized queries.