Skip to content

Protect IIS from SQL Injection using URLScan 3.0 Beta

UPDATE 2021: Since writing this many years ago nobody uses URLScan 3.1 any more and the download links no longer work. Instead, for modern Microsoft IIS Servers you should look at Request Filtering which is built-in. Or just go use a web application firewall, like Imperva or CloudFlare!

UPDATE: Since writing this, Microsoft have released URLScan 3.1 which you should be using -> ( – no longer valid)

If you’re not using URLScan Beta 3.0 then you’re just asking for trouble these days. There has been a recent ramp up in activity with SQL Injection attacks (amongst others) so you need to be very careful if you’re running a Microsoft IIS Web Server.

Getting URLScan 3.0

For information about Microsoft’s URLScan 3.0 Beta –

After you install it, fine the urlscan.ini file which is located in C:\Windows\System32\inetsrv\urlscan.

The default configuration file is fine for most web servers (unless you’re hosting Exchange OWA because you’ll need to allow a few more verbs that RPC uses).

What does a SQL Inject attack look like?

Almost all of the SQL Inject attempts we’ve been seeing look very similar to this:

RawURL='/somepage/somepage.asp’, QueryString='id=1042;DECLARE%%20@S%%20CHAR(4000);SET%%20@S=CAST

If you decode this using Microsoft SQL Query Analyser you will see that it is a bit of SQL designed to scan through all the tables in the database and append a <script></script> tag into  any varchar field with enough space at the end.  This is done in the hope that some of those varchars will end up being rendered back onto the website, thus providing the attack vector to visitors of your website.

Suggested Changes to URLSCAN.INI

Under [DenyQueryStringSequences] found at the end of the urlscan.ini file, ours now looks like this:

; If any character sequences listed here appear in the query; string for any request, that request will be rejected.
char(      ; Used in those big encoded SQL Inject attempts
cast(      ; Also be used in SQL Injects
&lt;          ; Commonly used by script injection attacks
&gt;          ; Commonly used by script injection attacks

We figure that nobody ever needs to use char( or cast( in any real URL, and thus far it has successfully caught many attempts.  You could also consider other character strings like exec for example.  It is up to you, and depends what you see come through.

Other things to look out for are the file extensions, you’ll need to comment out .exe if you host any download files.

And also under [DenyUrlSequences] look out for this line:

&   ; Don't allow multiple CGI processes to run on a single request

If you have any URLs that contain references to files with the ‘&’ character (some people do this particularly with photos where a filename might be ‘John&Mary.jpg’) be warned that any server requests for these files will result in URLScan blocking them, so you might want to uncomment that line above.

And remember, Take Care Out There!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: