Re: IIS6 - URLScan and MaxQueryString

Julie wrote on Tue, 7 Oct 2008 04:06:25 -0700 (PDT):

I've been running URLScan 2.5 on a Windows Server 2003 system, due to a
problem with that <insert swear word here> SQL Injection attack that
went around.

One of the things that I did was set MaxUrl=260 and
MaxQueryString=512. Since the query string that does this runs over
1000 characters, it worked pretty well; occasionally some would get
through to the website (I could never figure out why) but I have code
in place that searches again for % and DECLARE and such, and just
redirects to a 404 page, while I've been slowly but surely modifying
the problematic pages.

Yesterday we got zapped again...almost the same attack, except that it
used a POST command instead of a GET command, and had odd % in between
ALL of the SQL keywords I was searching for, for the redirect. (e.g.
DEC%LARE%20) so my ASP didn't catch it. The thing is, URLscan didn't
catch it either, even though A) the querystring was 1118 characters and
B) the % is the the DenyURLSequences section.

I need to keep this from happening while I am finishing fixing the ASP
in the problem pages. I upgraded to URLScan 3.0 (which of course uses
the same .ini file). Anyone have a clue what I may have done wrong in
configuring URLScan? As I said, works MOST of the time - lol. Will I
have the same problem with 3.0?

Any guidance would be received gratefully. Server management/security
is not my strong point.



POST data is not a querystring - the data is sent in the HTTP request body,
not in the GET request header.

Do you have an included file used throughout your ASP Application? If so, a
quick and dirty way to work around not taking your site down while you sort
out all the issues is to put a check in one of the include files to look for
the SQL in the Request.Form() and/or Request.QueryString() collections, and
in the event of either return a suitable response and stop processing the
page. It's not as efficient as URLScan, but in the case of POST data as you
have already seen URLScan is going to stop these requests. You can also do
some additional handling in the ASP code to normalise the strings before
checking them, making it easier to handle.

As a quick and easy solution, to most if not all of the current batch of SQL
injection requests, and assuming you are using SQL Server, just deny SELECT
to the sysobjects table for the login used by the ASP application - if the
injection code can't get a list of table names and varchar/char/text columns
then it won't run anyway. Ideally (and I guess you already realise this) you
need to parameterise your queries and lock down INSERT/UPDATE to only those
tables/columns that are required for your application to work.