SQL injection is nothing new, but it’s not every day that you read about a famous, widely-read journal like BusinessWeek getting hacked and distributing malware. Apparently BusinessWeek readers were directed to download malware from a Russian site (that has since become unavailable).

SQL injection attacks are relatively easy to protect against. One good way to prevent SQL injection is to use parameterized statements, also called prepared statements. These involve the use of placeholders in SQL queries, which are later filled-in by the database with a subsequent call. Thus, raw SQL is never executed, instead, a prepared query is created, and then its parameters are bound in order. Here’s a simple example (in C++):

stmt = "SELECT * from USER WHERE userID = ?";
/* ? is the parameter placeholder
 * stmt is prepared, and then the parameter is bound using a bind_param()
 * call
 */

In this way, user input is only bound to a variable with pre-determined constraints (max length, type, allowable characters, etc.).

Some other common defenses against SQL injection are user input escaping and network security devices that do pattern analysis on traffic. Input escaping is tricky, because attackers can be clever and use Unicode characters and other techniques to bypass typical escaping rules. So web developers should be aware of these techniques. IDS/IPS devices can provide an additional layer of security to detect and block traffic that matches knows SQL injection signatures.

One interesting new development in the last few years is the emergence of application layer filters such as ModSecurity. These modular firewalls plug-in to existing application servers such as Apache, and provide an additional layer of protection against web-based attacks.

As always, employing a defense-in-depth strategy is strongly recommended for mitigating these and other classes of attacks.