This is not how you should be doing things. Trying to eliminate "known bad values" are a losing proposition. Certainly you should test the type of all user supplied input - that's simply good programming. But when you connect to your DB to perform some query, use ADO Command objects and ADO parameters. Cheers Ken > -----Original Message----- > From: thelist-bounces at lists.evolt.org [mailto:thelist- > bounces at lists.evolt.org] On Behalf Of Todd Richards > Sent: Thursday, 29 May 2008 12:53 PM > To: thelist at lists.evolt.org > Subject: Re: [thelist] Website Hacked? > > > On Wednesday, May 28, 2008 7:38 PM, Chris Anderson wrote: > > That would obviously depend on language/platform being used. What are > you > using again (in case I can help)? > > Classic ASP, so it looks like some of your examples were valid for me! > :) > > > > Actually, it would have been okay - if you used the cleansed integer. > > (i.e. the value of the string *after* it had been converted to an > integer) > > For example, if you used Val(id) in ASP to see if that converts > without > > error, it will convert "300;INJECTED SQL" as 300. > > If you then use id in the SQL it will append "300;INJECTED SQL". If > > however you did the following: > > cleanId = Val(id) > > Query = "select this from that where id =" & cleanId > > It would have been fine, because cleanId will only hold an integer > > (If using a type-safe language, converting the id to an integer > variable > > then using that would be even safer) > > > OK, that does make more sense to me. I was "checking" the ID, but then > using the same ID and not the "clean" version of it. Doh!