
Massive SQL Injection Attack 600.000++ - rockstar9
http://www.0x000000.com/?i=556
======
jrockway
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.

You would have to really go out of your way to be vulnerable to this. You
would have to build your query like:

    
    
        "SELECT * FROM foo WHERE bar=$user_supplied_data"
    

which I think we can all agree is retarded. Even the worst programmers I know
at least write something like:

    
    
        $user_supplied_data =~ s/'/''/g;
        "SELECT * FROM foo WHERE bar='$user_supplied_data'";
    

(although PHP and not Perl ;) But of course using bindvars is the easiest and
most correct solution.

It always amazes me how people go out of their way to write code that's more
complicated and less secure. What!?!

------
alex_c
"The attack is only successful when the program that is being injected does
not sanitize user supplied data."

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?

~~~
jrockway
Ah, my other post in this article was meant to be a reply to you. ENOBRAIN.

Basically, if you are using bindvars or even the simplest sanitation, you're
safe. This "attack" lets you inject expressions that need a ' in them without
a ' going over the wire.

------
tarkin2
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.

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?

Besides, what does he mean by"by separating the queries"? A space? Surely not.

I don't fully understand it. Anyone?

------
jws
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.

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.

