Massive SQL Injection Attack 600.000++

It looks like applications are vulnerable if they blindly stick the attacker-supplied data into the query. The difference between this and the usual variety is that it also gets past things that strip single quotes and then put the data into the query.<p>You would have to really go out of your way to be vulnerable to this. You would have to build your query like:<p><pre><code> "SELECT * FROM foo WHERE bar=$user_supplied_data" </code></pre> which I think we can all agree is retarded. Even the worst programmers I know at least write something like:<p><pre><code> $user_supplied_data =~ s/'/''/g; "SELECT * FROM foo WHERE bar='$user_supplied_data'"; </code></pre> (although PHP and not Perl ;) But of course using bindvars is the easiest and most correct solution.<p>It always amazes me how people go out of their way to write code that's more complicated and less secure. What!?!

"The attack is only successful when the program that is being injected does not sanitize user supplied data."<p>Well, which is it? Does "regular" sanitizing prevent it, in which case is there anything new about this other than the massive scale? Or is the news that it sidesteps sanitizing because it's hex-encoded, in which case the statement is false?

The site said the injection is Hex encoded. Therefore, sanitising the input won't work because the injection isn't using any single quotes at all. To be honest, I have no idea how to sanitise Hex encoded input, in either MS SQL or MySql od Postgres.<p>The important part seems to be the fact that MS SQL allows "query stacking by separating the queries." Does this mean you can input multiple queries without using a semicolon (which you'd normally escape if you're not using a prepare statement) in MS SQL, and thus this is how the injection worms its way into your DBMS?<p>Besides, what does he mean by"by separating the queries"? A space? Surely not.<p>I don't fully understand it. Anyone?

This changes my perspective on SQL. It is not enough for a programmer to know "enough SQL to get by". He must know every feature and syntactic quirk of his targeted engine to write secure code and paste up queries. Here we see an obscure vendor specific function that almost no one would ever seek out leading to a security failure.<p>Personally, I never paste up queries anymore. I always use parameter substitution. It leads to some awkward but idiomatic constructs when dynamically constructing a predicate, but I sleep better.