UrlScan and SharePoint

UrlScan is a security tool that restricts the types of HTTP requests that IIS will process. This tool has number of different features which help you block specific HTTP request. Some of the outstanding features that UrlScan can help is the prevention of SQL Injection, XSS, HTTP Population attack. This sounds like a cheap weapon compared with any other security tools in the market. Ideally in any IIS web server UrlScan is supposed to be installed.  In many organizations, UrlScan is part of the entirely hardening guideline for IIS. Now the question of UrlScan for SharePoint comes out. Is UrlScan still helpful to your SharePoint site? Would SharePoint be an exception? In this article, I’m going to share just a little of my experience when working with UrlScan in SharePoint environment.

Allow HTTP Method

In UrlScan , the UseAllowVerbs is used to allow or block HTTP methods. Indicated clearly if you set this parameter to 1 UrlScan will read the [AllowVerbs] section and reject any request containing HTTP methods that is not explicitly listed. If set to 0 you need to put all HTTP methods in [DenyVerbs] section you want to deny. In almost hardening guideline, it’s stated that GET and POST are allowed. Other else must not be allowed. Ironically, SharePoint requires more than GET and POST. If you try to inspect HTTP methods when exploring client integration features in SharePoint by Fiddler you will realize that some special methods which are part of WebDAV are called. These may include HEAD, OPTIONS, PROPFIND, PUT, MKCOL or so on. With this fact, only allowing GET and POST will not fully make your SharePoint work.

Below is the sample log of UrlScan when you deny PUT then perform uploading multiple documents.

One of the very common cases you have to deal is to be in the middle between your end users and the security team you are required to bypass. If you deny something that the security team needs but this will then prevent your end user from doing something, chances are you should talk to the stakeholder who has power and authority to make a decision. But if this person cannot sort that out you need to implement number of different ways to handle HTTP methods. This article provides you real-world case that I encountered and may give you some idea: Approach to preventing PUT method in SharePoint

Allow Extension

Similar like HTTP method allowance above, UseAllowExtension is where you define whether you go with white or blacklist. The feature is exactly the one in Request Filtering I wrote in the past: IIS Request Filtering Whitelist and SharePoint 2013

Make sure you don’t miss any extension which would break SharePoint features. Sometimes you are asked to justify each extension, for example .config. This takes pretty much of time for examination by blocking extension then performing SharePoint functionality test.

Normalization URL

If you are confident enough with URL parsing, you can set NormalizeUrlBeforeScan to 0. Otherwise keep it by default as 1 because SharePoint mostly uses normalized URL to mitigate canonicalization attacks.

Verify normalization

One of the features in UrlScan is the verification of normalization. This feature helps defend against canonicalization attack, where a URL contains a double encoded string in the URL. Keep VerifyNormalization by default as 1 to improve security.

Allow high bit character

In UrlScan, the AllowHighBitCharacters is where you can set to reject request where the URL contains a character outside of the ASCII character set. In SharePoint you may open document or item which contains a high-bit character in the title. You should set this feature to 1 by default. However, there is a risk when setting to 1 which may open the door for UTF-8 based attacks.

Allow Dot in path

This is one of the things that I recently encountered. One of my development team named a package folder with dots (e.g. sp.app.lib). If you set AllowDotInPath to 0, UrlScan will reject requests that contain multiple instances of the dot (.). For example, the CSS file cannot be rendered if setting to 0: http://sharepoint.contoso.com/_layouts/sp.app.lib/style/corp.css

Remove server header

Almost hardening guideline, I have seen, server header needs to be removed. The reason is that it mitigates the risk if somebody knows server name then tries to exploit. Ironically SharePoint Designer does need server header. Every time you connect to a SharePoint site by SharePoint Designer, it actually calls /_vti_bin/shtml.dll/_vti_rpc to request the web server version via POST method. If you remove server header you will encounter 400 Bad Request message and will not be able to connect to your SharePoint site.


There are two features related to logging in UrlScan 3.0: EnableLogging and PerDayLogging. To monitor UrlScan for better troubleshooting, set it to 1 in EnableLogging. Keep PerDayLogging by default.

Allow late scanning

This feature must be set to 1 because FrontPage Server Extensions which is part of SharePoint requires. Setting to 1 also means the UrlScan will register itself as a low priority filter. It may expose security threat but as the dependency of FrontPage Server Extension you have to be aware of.

Use fast path reject

In real-world scenario, this feature should be set to 0. If it is set to 1 you cannot implement a custom 404 error which is required in almost hardening guideline. Providing friendly message when error happens is to mitigate information leakage attack would utilize.

Unescape query string

Always set it to 1 for better security. This feature helps you perform two passes on each query string scan. If it is set to 0 checks based on the query string will be unreliable.

Other settings

There are a few special parameters to consider. The first one if MaxAllowedContentLength. If you want to increase maximum upload size in SharePoint, the configuration in web application is not enough. You need to adjust MaxAllowedContentLength accordingly. The second one is MaxURL parameter. SharePoint by default only supports the URL up to 260 characters. If you set to a number less than 260, you will encounter with 404 error. The last one is MaxQueryString. If you are a novice, you may encounter with long query string as your approach is not practical. Consider setting this as proper as you need and make sure you don’t allow too long query string which may allow attack to exploit your SharePoint website with ambiguous query.


If you have read my articles related to security stuffs with SharePoint, you probably realize the fact that dealing with vulnerability assessment & security in SharePoint scenario is not that easy. What you would have to do is get all of the findings out of the report, or justify your customer if any fail positives. If not, chances are you are required to contact Microsoft for confirmation. Unluckily as I had several times working with Microsoft, I’ve already known that they never protected me in this area. Even a few findings in SharePoint out-of-the-box features it’s much harder for Microsoft to evaluate and give you an official confirmation. Dealing with security in SharePoint is always challenging!

Always test with UrlScan carefully before you implement it in production environment.


f you wish to collect my articles related to SharePoint security, see the list below.


  1. April 23, 2016 — 4:17 am

    Awesome and detailed blog post.

Leave a Reply

© 2018 The Soldier of Fortune.