Microsoft distances itself from SQL attack

The attack method here is just a generic SQL injection attack. All the attack tool does is search Google for URLs where the address ends in ".asp" and looks for a query-string parameter named "a". It then injects a chunk of T-SQL text which modifies the contents of every column of every table to include a piece of script.

You cut off this problem at the knees by not allowing user input to ever be processed as part of the SQL statement. To do this, always, always use parameterised queries. For preference I use stored procedures, but the key is to treat user input as a parameter value, never part of the statement. If you need a dynamically-shaped query, you can still use parameters.

There's simply nothing here that Microsoft can fix. It's coincidental that Microsoft technologies are attacked. You could use the same technique with Oracle (injecting PL/SQL text) and attack PHP-based servers by looking for a .php extension.

The traditional avenue for malware, of looking to exploit OS vulnerabilities, is drying up (particularly on Windows - Microsoft's Security Development Lifecycle is working). In comparison the number of application and particularly website vulnerabilities is exploding.

In Oracle, you simply create a separate schema user and don't allow them to modify table design or access the system schemas. It's actually a bit harder to do that in SQL Server (despite the GUI) as I recall, but it should be fairly easy.

Once you change the connection string, you're away. Nice and secure - anything which tries naughty things will fail. Yet few DBAs and developers seem to bother with this and have the misguided idea that another few dozen stored procedures that make coding much harder and less maintainable are the holy grail of web development.

You pay a small fortune for SQL server, You pay a small fortune for Microsoft training on how use SQL Server. 
They teach you to actively go out and make insecure sites.
But its not their fault!

>> However, according to Wired, one of the problems is that IIS is poorly wired.

Horse-shit.

There is one difference which makes these compromises worse than the usual PHP app breakages. SQL Server (and others such as Oracle) allow multiple SQL statements to be executed in one call (by separating several statements with semicolons); MySQL (which most of the broken PHP apps use) only allows one statement per call.

This means that MySQL injections are limited to monkeying with the existing statement they're being injected into. This is still bad, but generally results in an application-layer exploit that has to be tailored to the target app. Whereas these SQL Server injections can simply dump a semicolon in to end the application's query, and follow it with arbitrary destructive statements without having to know anything about the application. This results in the more widespread infection and greater database damage.

There is no really compelling reason to allow multiple statements in one line so the situation could be mitigated by disallowing this. However the blame must ultimately lie on the idiots who keep writing ASP and PHP pages with SQL queries cobbled together by concatenating strings... and the real culprits, the scripting tutorial writers who still encourage this dangerous practice.

As previously mentioned- this is not an issue specific to either SQL Server, or IIS. 

The article claims IIS is 'poorly wired' without any explanation of what 'poorly wired' might mean, or any indication that the author even understands the meaning himself.

If you think about it, why should the web server be 'wired' to the database at all? Surely its the job of the programmer to wire their application to the database. The web server simply serves their application to the outside world.

Poor handling of query strings is the single most obvious point of attack for sql injection based exploits. Every programmer who doesn't want to be imminently looking for a new job should be coding to handle this as second nature.

In light of this, the comments that Microsoft are somehow to blame for this, or Tom's comment that they somehow 'teach us to make insecure sites' are utter nonsense. If Tom, or any of the programmers that created the affected site, had read any of Microsoft's programming books they would know better.