IIS Request Filtering Allow URL

Question

I am using IIS7 request Filtering (WebSite level) with 'Allow unlisted file name extensions' set to un-checked. After this setting when I access my web application say, _http:/machine_name/app1 then it fails. After adding correct file extensions under 'file name extensions' it starts functioning but it later fails when I surf other links inside my application. I found that I need to add URL's under 'Allow URL' but I do have huge number of URL list which need to be added for e.g.: '/app1/prop1', '/app1/prop1/services/', '/app1/prop2/repository'..... and more So, I see a pattern like /app1/* but 'allow URL don't allow any pattern matching. Is there any way to add Regular expression somewhere in IIS so that the matching URL's can be allowed.

Thanks in advance.

Answer 1

I think URLs like '/app1/prop1', '/app1/prop1/services/', '/app1/prop2/repository' don't work with 'Allow unlisted file name extensions' set to false because you didn't allow extensionless requests.

To allow extensionless requests, add <add fileExtension="." allowed="true" /> to your web.config as below:

  <system.webServer>
    <security>
      <requestFiltering>
        <fileExtensions allowUnlisted="false">
          <add fileExtension="." allowed="true" />
        </fileExtensions>
      </requestFiltering>
    </security>
  </system.webServer>

Please let me know if this helped or the issue still occurs.

Answer 2

@alexander-abakumov is correct. When allowUnlisted=false, one must include the provided xml (<add fileExtension="." allowed="true" />) to allow extension-less requests (e.g. /App/ or /Folder/).

Request Filtering Limitations

You're correct to use URL Rewrite for achieving RegEx pattern matching. Below are the limitations of Request Filtering.

• Stateless - Request Filtering has no knowledge of application or session state. Each request is processed individually regardless of whether a session has or has not been established.
• Request Header Only - Request Filtering can only inspect the request header. It has no visibility into the request body or any part of the response.
• Basic Logic - Regular expressions and wildcard matches are not available. Most settings consist of establishing size constraints while others perform simple string matching.

Still use Request Filtering

I would still recommend using Request Filtering since it operates so early in the IIS request pipeline; even before URL Rewrite. This gives you the opportunity to immediately discard bad requests. URL Rewrite can then be a second layer of request filtering.

IISRFBaseline

The information above is based on my PowerShell module IISRFBaseline. It helps establish an IIS Request Filtering baseline by leveraging Microsoft Logparser to scan a website's content directory and IIS logs.

For the fileExtensions setting there are two methods for establishing a baseline:

1. IIS Logs - by parsing prior successful requests and determining the extension of the request.
2. Content Directory - scanning the file system of the website content directory to see what file extensions are in use.

There are caveats to these two approaches which are described in more detail here. With two techniques, a markdown file is provided describing the methodology of each as denoted by the suffix IIS or FS.

• fileExtensions_FS
• fileExtensions_IIS

The result of these two techniques are combined, after removing bad requests, to create a baseline for this Request Filtering setting.

Answer 3

OK, at last I got the solution. The trick was not using 'requestfiltering' but 'URL rewrite'. It has the option to allow or deny URL based on the regular expression or Wildcard with the option 'Does not match the pattern'. I created rule for the URL/file which does not matches my application's pattern and deny those by redirecting a 404 type of error.