If you think you are good enough to write code resistant to SQL attacks, you are wrong. If you think the best coder in your company is good enough to write code resistant to SQL attacks, you are wrong. Now realize that it is neither you nor the best coder in your company that you have to worry about, but the performance of the worst guy employed by the team in Bangalore on his first day back at work after his mother's funeral.
All code by necessity has a weakest link. The best you can do is make sure it is the library you are using.
(Incidentally, this also describes manual memory allocation.)
You're still "doing it yourself" even if you use parameterized statements.
My take on this article has changed in the past hour; before I thought it was cute but inaccurate, but its state is transitioning to "actively evil".
The reality is that companies that have a lot of SQL but never have SQLI vulns do all of the following:
* Use an ORM like Hibernate (or AR or Django) for "front-line" database queries
* Standardize on parameterized statements for the complex stuff
* Design and implement a "house style" for query builders and "modular" SQL statements
* Factor as much as possible into stored procedures in the database
* Run databases in least-privilege mode, so that code that only needs read access to a few tables can "revoke" the unneeded privileges
* Sweep their codebases for SQL statements and audit them with a team signoff
By "do all of the following", I mean "A-L-L of the following". The ones that don't are the ones that tell us "there's no way you're going to find SQLI in your audit; you'd get fired for having concatenated SQL here", and then lose their entire database in the first week.
I don't mean to sound obnoxious. I just hate the idea of people walking around thinking their code is safe because they switched to ? instead of "'" + x + "'".
Well to be fair, the article isn't claiming that parameterized queries will make all your DB transactions secure, just that they will prevent injection attacks. Which is true isn't it?
Unless you have dynamic code generation in your sql, parameterized queries make injection attacks impossible, don't they?
But I still feel like what is missing from this discussion is why parameterized queries are not vulnerable to injection. Are they just better implemented and better tested? Is there some technological reason why they are superior, something they are capable of doing that a concatenated string cannot?
I feel like having this discussion without telling the readers why the solution is the solution is analogous to just doing a bunch of hand-waving. "Don't do that, do this" doesn't really teach people why "this" is better.
The net effect is, there's no opportunity to mix query structure and parameter, because by the time the database looks at user input, it's already fixed the query structure in place.
You do not get the same benefit by aggressively quoting; among other things:
* Quoting can fall to character set attacks
* You still may need to handle truncation
* Different quoting regimes are required for different parameter types
It's possible to safely do concatenated sanitized SQL (ActiveRecord does it), it's just hard. It's also possible to have injectable parameterized queries, or even injectable stored procedures (for instance, if the procedure uses dynamic SQL). There's no panacea.