where's the salt?

08/23
2008

SQL injection attacks: Part 2: Answers (6,169 views)

DiggThis

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


For all you guys looking for ways to detect vulnerable servers and code, try these links now:
Microsoft Source Code Analyzer for SQL Injection
or:
Scrawlr

Cleanup:
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.

Prevention:
* 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.

(Visited 103 times, 1 visits today)

Tags:

Date posted: Saturday, August 23rd, 2008 at 7:58 am (15 years, 7 months ago.)
Posted in: business mix, tech mix
Comments RSS Feed Comments RSS Feed
Reply
Ttrackback

2 Responses to “SQL injection attacks: Part 2: Answers”

  1. 1

    HI
    looks very interesting!
    bookmarked your blog.
    john brightman

    john brightman on May 24th, 2009 at 4:57 am
  2. 2

    […] (8-23-2008): Looking for answers? Check Part 2 UPDATE (8-25-2008): Securing your forms to prevent future […]

    SQL injection attacks: no end in sight? [internet mix] on March 13th, 2010 at 2:40 am

Leave a Reply


search

Categories

css.php