Looks like the misreporting of the mass SQL injection attack continues. The exploit is associated with MS SQL Server, not IIS or ASP. It’s confusing because most people run the full Microsoft stack, but the exploit will work against any site that does not prevent SQL injection and uses MS SQL as its database. (This misreporting was most recently seen at the Mass Attack FAQ at hackademix.net and Wired: Compiler.
Also it’s worth noting that the best solution to this problem (noted in the comments on yesterday’s post by Simon Willison) is to use prepared statements to generate database statements rather than building them using string concatenation.
If you’re a PHP developer using MySQL, that means using mysqli. For most other languages, that means simply not misusing your database library. For example, with JDBC (Java’s generic database access library), you can build SQL statements with string concatenation, but it’s just as easy to use prepared statements. There’s a good explanation of how to use prepared statements to avoid SQL injection attacks in ASP.NET at Scott Guthrie’s blog.
I think these days most people are pretty good about using prepared statements for inserts and updates, but they still get lazy and use string concatenation when building WHERE
clauses, especially in cases where expressions are added to the SQL query dynamically. When doing so, the key is to go through the process in two steps. Building the statement dynamically but still leaving the placeholders in the query so that a prepared statement can be used and the parameters of the statement can be bound to it properly. It’s a bit more work, but it’s essential for security.
Mass SQL injection update
Looks like the misreporting of the mass SQL injection attack continues. The exploit is associated with MS SQL Server, not IIS or ASP. It’s confusing because most people run the full Microsoft stack, but the exploit will work against any site that does not prevent SQL injection and uses MS SQL as its database. (This misreporting was most recently seen at the Mass Attack FAQ at hackademix.net and Wired: Compiler.
Also it’s worth noting that the best solution to this problem (noted in the comments on yesterday’s post by Simon Willison) is to use prepared statements to generate database statements rather than building them using string concatenation.
If you’re a PHP developer using MySQL, that means using mysqli. For most other languages, that means simply not misusing your database library. For example, with JDBC (Java’s generic database access library), you can build SQL statements with string concatenation, but it’s just as easy to use prepared statements. There’s a good explanation of how to use prepared statements to avoid SQL injection attacks in ASP.NET at Scott Guthrie’s blog.
I think these days most people are pretty good about using prepared statements for inserts and updates, but they still get lazy and use string concatenation when building
WHERE
clauses, especially in cases where expressions are added to the SQL query dynamically. When doing so, the key is to go through the process in two steps. Building the statement dynamically but still leaving the placeholders in the query so that a prepared statement can be used and the parameters of the statement can be bound to it properly. It’s a bit more work, but it’s essential for security.Commentary
securityWeb development
Previous post
Truer wordsNext post
Donald Knuth on unit tests