SQL injection attacks: Part 2: Answers (6,115 views)
While the effect yesterday’s post had was unintentional (I only wanted to complain about the effect those requests have on our and our clients’ server statistics), it seems that a lot more people than I would have anticipated are affected and are looking for answers.
So in this post, I am trying to provide help and some answers.
UPDATE (8-25-08): How to secure your forms and prevent future attacks
Replace script tags from your database (absolutely no warranties – check the URL/path of the domain and script – in this case http://www0.douhunqn.cn/csrss/w.js – as well):
DECLARE @T varchar(255),@C varchar(4000); 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+']=replace(['+@C+'],''"></title><script src="http://www0.douhunqn.cn/csrss/w.js"></script><!--'','''')'); FETCH NEXT FROM Table_Cursor INTO @T,@C ; END; CLOSE Table_Cursor; DEALLOCATE Table_Cursor;
Quick Fixes to prevent more attacks (until you had time to secure every single query):
Check for suspicious Strings in Query Strings via an included function before serving any pages (Chances are nobody is supposed to submit certain statements in a parameter in the first place).
Use the RewriteEngine to check for and react to those strings (e.g. serve a 401 page instead).
These are quick fixes only and should not serve as long-term solutions: If the attacker modifies the SQL statements and you are only checking for e.g. DECLARE you have the same problem all over again.
* Never trust Query Strings.
* Escape them properly.
* Check the TYPE of your variables. If you expect numeric values, check for numeric values.
Demo – Test it:
We’ve created a demo page so you can check how a rewrite rule or an include function might change the way your pages are served:
SQL injection attack attempt demo page: (will open in new window)
You can also use the page to translate the code from your logfiles:
SQL injection attack attempt demo page without Query String
I hope this answers at least some of your questions. If you are still lost, feel free to either leave a comment and I will try to answer your questions ASAP or email me directly.
PS: I agree with everyone who said it’s not a pure SQL injection hack, but it’s also not a pure XSS hack either.