UrlScan v3.0 RTW Released

About 2 months ago we released the beta for UrlScan v3.0 to address customer concerns with automated SQL injection attacks and we have been busy since refining it with the help of our customers, community and MVPs. You can download the bits at the links below.

UrlScan v3.0 RTW for x86

UrlScan v3.0 RTW for x64

You can also check out the updated walkthroughs for UrlScan v3.0 that covers the new features since Beta.

Using UrlScan

UrlScan Setup

Common UrlScan Scenarios

UrlScan FAQs

Here is a summary of the feature additions to UrlScan v3.0 RTW

1) W3C formatted logging.

UrlScan v3.0 RTW has W3C formatted logs so that analyzing log files is more accessible by writing queries against them using Log Parser. The following are the fields in the new log format with a brief description.

Date: Date of incoming request
Time: UTC time for incoming request
c-ip: Client IP address
s-siteid: SiteID for the site that processed the request
cs-method: Method (verb) of incoming request
cs-uri: URI of incoming request, including query string
x-action: Action performed by UrlScan. Either rejected or logged
x-reason: Reason for UrlScan check being triggered.
x-context: Portion of request this check is applicable to, e.g. URL, query string etc
cs-data: Data in the request that triggered the UrlScan check 
x-control: UrlScan configuration data that caused the UrlScan check to trigger

2) Allow rules for URLs and query strings

UrlScan v3.0 RTW gives you the ability to specify a "safe" list of URLs and query strings that will by pass all UrlScan checks. This gives administrators the ability to configure UrlScan to allow certain URLs that would otherwise trigger a UrlScan check.

 

Here is the link to my blog when UrlScan v3.0 Beta was release

3 Comments

  • I would like to allow a search page to accept all text in the query string. To do this I added the result page to the [AlwaysAllowedUrls].

    One thing that is ambiguous from the documentation is if the [AlwaysAllowedUrls] settings also bypasses the custom rules and if the pages listed in [AlwaysAllowedUrls] can have any query string values. It does not seem to be the case but I thought I would check. Could anybody shed any light on this?

    Thank you.

  • I've noticed the same about [AlwaysAllowedUrls].

    I've also noticed [AlwaysAllowedQueryStrings] works, if you have a single query. But, if you have an allow entry for a=1, but the user requests /page.asp?a=1&b=2 it still blocks it, because the exact query string a=1 isn't met.

    To an extent, this makes sense. However, with no method of using 'wildcards' or specifying b must equal a digit, or something of that nature... it makes it very difficult to allow dynamic forms to act as normal.

    I understand this is a 'stop gap' solution while you fix sites... but a bit more granularity would be nice. Particularly considering you may have a large number of pages which you've fixed and want to allow bypasses for, while still protecting some you've not managed to sort out, yet.

  • How to block request which are on http/1.0 protocol using URLscan 3?

Comments have been disabled for this content.