IE exploit spreading via SQL injection

It’s no news that the latest 0day for IE is spreading via SQL injection attacks. What is news is why are we still suffering from SQL injection? We’ve known for over eight years how to utterly end SQL injection. I’m sick of writing about it. We should not be talking about SQL injection any more. 

This is a call to arms – SQL injection is a done deal. It stops today!

I call on:

• Acquirers of software to inspect nvd.nist.gov and determine if the software your about to acquire has ever had SQL injection. If so, make sure it does not use dynamic queries today. If it does, do not acquire or use it. 
• Managers of software libraries to investigate all software in their possession in the same way. If it has had SQL injection in the past, it’s likely that it still has dynamic queries today. Write to the project and demand a version that has no dynamic queries. Make transition plans to get off faulty software if they do not respond or cannot respond in a reasonable time frame. We did this for the Y2K effort, it’s not that hard
• Open source project houses such as Google Code, Microsoft’s CodePlex and SourceForge should put projects on notice that have dynamic queries that their downloads page will be disabled by Dec 31, 2009 if they have any dynamic SQL queries in them. I know this is a lot of work, but I can’t think an easier way to provide outreach to so many projects simultaneously.
• CISO and CIOs and lead architects to outlaw the use of dynamic and concatenated queries in your policies and coding standards and to mandate the use of un-injectable alternatives
• Developers to stop using dynamic queries and concatenated strings in prepared statements. With all haste, migrate all your code to prepared statements, stored procedures (noting that these still may have issues), or an alternative data storage mechanism, such as Hibernate or Active Record 
• Frameworks to deprecate and eliminate dynamic SQL query interfaces (Java’s Statement, PHP’s mysql interface, etc) with extreme urgency. Today, they should emit warnings in DEBUG mode, and in six months to a year, they should cease to exist
• Frameworks should inspect prepared queries in DEBUG mode, and if there’s a WHERE clause without a placeholder, the query should raise a warning during compilation or runtime depending on how your language operates. Of course, there are SQL queries that have where clauses that are static, but these are the exception not the rule. We need to help developers pin point weak statements, so a pragma or comment mechanism to shut the warning down would be helpful too
• If you audit or review source code, you should mark all dynamic SQL queries critical. Because they are critical risks. Without understatement or hyperbole, dynamic queries are an obvious clear and present danger to the world’s IT infrastructure and they simply do not need to exist.  

SQL injection stops today! There’s an awful lot of code that needs fixing, so let’s get cracking.