URLScan Update

From: Lester, Don (dlester@CLINITECH.NET)
Date: 11/08/01

Message-ID:  <6CC25018D3C8D411B2F500508B4456AE8E2013@wvc-exchange>
Date:         Wed, 7 Nov 2001 15:46:26 -0800
From: "Lester, Don" <dlester@CLINITECH.NET>
Subject:      URLScan Update

I have received a lot of feedback regarding my earlier post about URLScan.
It turns out, unfortunately, the work-around I posted does not work in all
cases. Out of frustration, I opened a ticket with Microsoft support. I
wish the result of that was better news, but here is what we found:

The bad news is that the version you can download from the web site does not
work correctly. They are supposed to fix this, but when/if that will ever
actually happen is anyone's guess.

The good news is that if you are one of the lucky people that has a
Microsoft Technet subscription you should have recently received the greatly
anticipated Microsoft Security Tool Kit CD (if not, you can order it from
Microsoft). I do not like how this CD works. It does a lot of things
without asking, and the installation itself does not seem to allow you to
skip the IIS Lockdown installation and proceed to the URLScan installation.
It is one continuous operation that installs one module after another.

BUT, after all of this, it is still bugged. Microsoft alleged it was fixed,
but I worked with their support staff to find the means to make the
UseAllowExtensions option work for default pages. It still isn't documented
anywhere, and hopefully they will eventually fix their broken product. The
programmer asserted that it was working as intended, and should only allow
the extensions specifically listed. I suggested he look at any standard
firewall product and compare his work with the rest of the world's standard
practices. I also invited him to present a scenario when an IIS server
should not serve the default page (ie, /) for a given directory.

I had a lot of requests for the INI file. This is the one I am currently
using for testing, but it will be restricted even more before this box goes
into production. The lone . in the allow extensions section is intentional.
That is the workaround for the bug. It does work here for all cases I have
run it through, but that doesn't mean it will work for everyone (though I
hope it does). Microsoft has some work to do on their security package. If
you want to be sure you are using the same version, my urlscan.dll is
version 6.0.3547.0.

UseAllowVerbs=1 ; if 1, use [AllowVerbs] section, else use
[DenyVerbs] section
UseAllowExtensions=1 ; if 1, use [AllowExtensions] section, else
use [DenyExtensions] section
NormalizeUrlBeforeScan=1 ; if 1, canonicalize URL before processing
VerifyNormalization=1 ; if 1, canonicalize URL twice and reject
request if a change occurs
AllowHighBitCharacters=0 ; if 1, allow high bit (ie. UTF8 or MBCS)
characters in URL
AllowDotInPath=0 ; if 1, allow dots that are not file
RemoveServerHeader=0 ; if 1, remove "Server" header from response
EnableLogging=1 ; if 1, log UrlScan activity
PerProcessLogging=0 ; if 1, the UrlScan.log filename will contain
a PID (ie. UrlScan.123.log)
AllowLateScanning=0 ; if 1, then UrlScan will load as a low
priority filter.
PerDayLogging=1 ; if 1, UrlScan will produce a new log each
day with activity in the form UrlScan.010101.log
RejectResponseUrl= ; UrlScan will send rejected requests to the
URL specified here. Default is /<Rejected-by-UrlScan>
UseFastPathReject=0 ; If 1, then UrlScan will not use the
RejectResponseUrl or allow IIS to log the request

; If RemoveServerHeader is 0, then AlternateServerName can be
; used to specify a replacement for IIS's built in 'Server' header


; The verbs (aka HTTP methods) listed here are those commonly
; processed by a typical IIS server.
; Note that these entries are effective if "UseAllowVerbs=1"
; is set in the [Options] section above.



; The following request headers alter processing of a
; request by causing the server to process the request
; as if it were intended to be a WebDAV request, instead
; of a request to retrieve a resource.



; Extensions listed here are commonly used on a typical IIS server.
; Note that these entries are effective if "UseAllowExtensions=1"
; is set in the [Options] section above.


.. ; Don't allow directory traversals
./ ; Don't allow trailing dot on a directory name
\ ; Don't allow backslashes in URL
: ; Don't allow alternate stream access
% ; Don't allow escaping after normalization
& ; Don't allow multiple CGI processes to run on a single request

Relevant Pages

  • Re: Questions URLSCAN
    ... if there haven't been any requests rejected by URLScan ... URLScan creates a new log file each day. ... Microsoft PSS Security ... | 1) Try to access your site with .exe type of request, ...
  • URLSCAN on IIS6 config
    ... I am having some problems getting URLScan 2.5 running ... in the url and rejecting the request ... Request will be rejected. ... IIS server. ...
  • URLSCAN 3.0 problem ("Invalid index.")
    ... I have URLSCAN 3.0 installed on a 32-bit Win2003+SP2 IIS server, and if the URLSCAN.INI file includes the following: ... Then it works fine, but if I uncomment the Max-Content-Type line (or add any other Max-* request header lines) then URLSCAN rejects every single request with an "Invalid index" error message in the returned in HTML, and does so without logging anything to the URLSCAN.LOG file either. ...
  • I got a response from Microsoft Permission/Copyright group regarding masm
    ... I explicitly requested commercial use permission. ... request are listed below for reference. ... Company agrees to be bound by the terms of the attached Microsoft ... MASM32 software package. ...
  • Re: Theory behind ASP.NET mobile device capabilities?
    ... Microsoft has it's own implementation of the Device Capabilities assessment ... HTTP modules are classes that have access to the incoming request. ... information about the mobile device capabilities is written in the request. ... Microsoft Certified Professional ...