Use prepared statements or... use prepared statements

While performing security assessments at Rendition Infosec, one of our most common findings is SQL injection.  One great way to cut down substantially on SQL injection is to use prepared statements.  Note: I didn't say that prepared statements will eliminate all SQL injection, but its a critical first step.  This is particularly true for complex injection types, such as 2nd order SQL injection.

But refactoring code is hard and many customers will try to eliminate only those bugs that were identified in a security audit.  That of course is a good start, but stopping there is a mistake.  Code that does not use prepared statements will likely cause problems eventually.  Trying to put patches on your code will cause problems too.  It's like propping up that rotting floor joist instead of actually replacing it. Bottom line: even if the program isn't currently vulnerable, it is too easy for a future code change create a vulnerable condition.  Prepared statements make this substantially less likely.

So to companies unwilling to use prepared statements in their code and refactor to their code I say this: use other prepared statements.  Coordinate with your PR team and have them prepare statements (see what I did there?) explaining why you were compromised when you could have fixed the issues found in the code audit earlier.  Basically, if you don't use prepared statements in your SQL queries expect to be exploited.  Don't get caught unprepared to handle the media backlash when you lose customer information or regulated data.