[thelist] Website Hacked?

[Ken Schaefer]

The reason we have SQL injection issues is because programmers (mostly) suck at writing SQL parsers. But we still try anyway. We concatenate SQL commands (e.g. SELECT ...) with actual data, and then try to make sure the data is sane.

That's the wrong way to go about it. Most DBMSes already have excellent parsers that can build a query plan, and then you just supply the data.

So, *use* the prepared statement technology that exists for your DBMS! If you are using ASP, then ADO provides Command objects that you can use against sprocs (or even inline SQL). ASP.NET likewise provides prepared statement support.

Use this, and you are then relying on the DBMS to take your SQL statement, and your data, and prepare the necessary query execution plan. And barring a bug in the DBMS implementation, you'll be invulnerable to SQL injection attack.

Cheers
Ken


> -----Original Message-----
> From: thelist-bounces at lists.evolt.org [mailto:thelist-
> bounces at lists.evolt.org] On Behalf Of Chris Anderson
> Sent: Sunday, 25 May 2008 9:01 AM
> To: thelist at lists.evolt.org
> Subject: Re: [thelist] Website Hacked?
>
> > The more sophisticated hackers will encode their SQL statements like
> > this:
> >
> > Store.asp?id=300;DECLARE%20 at S%20VARCHAR(4000);SET%20 at S=CAST(0x444
> > 5204054205641524348415228323535292C404320564152434841522832353529
> > 204445434C415245205461626C655F437572736F7220435552534F5220464F522
> > 2736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20
> > VARCHAR(4000));EXEC(@S);
>
> Some go further and URLEncode *every* character (so DECLARE becomes
> %44%45%43%4C%41%52%45) to get around people checking for "SELECT",
> "EXEC", etc
>
> However if you use the 300 using a parameter that's configured as an
> Int
> - it should never hit the database anyway (so if you are using
> parameterised queries, you probably need to look elsewhere)