On the topic of my SQL Connections SQL Server presentation, one of the things I pointed out about recent SQL injection attacks is they aren't exclusively targeting data any longer. Sure, the hacks against MySQL.com did target data, but an attack occuring at the same time sought to embed redirect code to get users from a legitimate web site to one serving up malicious code.

From a SQL Server perspective, this isn't very advanced code. We can trap for the text phrase "char(" in a trigger and effectively rollback the transaction. Other examples of these sorts of attacks have intentionally obfuscated the SQL injection code to where we didn't have such an easy time of it and couldn't write simple triggers to protect ourselves when the web application failed. And that's a key point that always needs saying: SQL injection is an application layer weakness, not a database one. The application is permitting bad input to come in and then passing it back to the database server. But in the event that you need to protect the web site and the time it will take to update the application code will take too long, simple exploits like this one can be prevented with a relatively easy to write trigger.