Monday, August 22, 2016

IIS 7.0 Web Site STIG V-2267 - Request Filtering

Problem

After enabling Request Filtering in IIS for your .NET website, some areas of the application no longer work as expected. This is often done to put your website in compliance with STIG Rule ID SV-32335r3_rule also known as IIS 7.0 Web Site STIG V-2267.

Solution

Add .NET file extensions to the Request Filtering list. These extensions are found here: ASP.NET Web Project File Types.

Begin by adding the extensions under "File Types Managed by ASP.NET", then test the areas of your website that had previously not been functional. If these areas still do not work, try adding the file extensions under "Static File Types" and then "File Types Managed by IIS". Make sure to not add any extensions that are not allowed by the STIG.

It may be regarded as bad practice to add file types to the whitelist that you do not need, so try to only add what you need.

If you have third-party tools that are breaking, those extensions will have to be investigated and added to the whitelist, if appropriate and allowed. Fiddler with help with this, as I explain below in "Other Things to Try."

Explanation

You may think that to find all the file extensions needed for the whitelist, you should explore the files and folders of your website and add all file extensions you find to Request Filtering in IIS. This does not work because there are files that are generated by your app at runtime that have extensions that aren't found in the website's folders. For example, .axd files are a commonly forgotten file extension that will break some areas of your site if they are not included in the request filtering whitelist.

You also need to keep in mind that if you simply allow all file extensions from ASP.NET Web Project File Types, you may be in violation of the STIG. Remember, the point of STIG V-2267 is to limit script execution.

Other Things to Try

Use Fiddler. With Fiddler running, navigate to a page in your application that isn't working and look for 404 errors. These indicate requests for resources that were not found. One reason these files can't be found may be that IIS's request filtering is denying access to them. Look at any 404 errors you are getting and try adding those file types to the whitelist in IIS. For example here is what we would see if .axd files were being denied.

Fiddler results when .axd files are not in the whitelist. Click to Enlarge

Wednesday, August 10, 2016

Unable to start debugging on the web server. Unable to connect to the web server. Verify that the web server is running and that incoming HTTP requests are not blocked by a firewall.

Problem

When trying to debug  your solution or project, hosted on IIS Express, the following error occurs:
Unable to start debugging on the web server. Unable to connect to the
web server. Verify that the web server is running and that incoming
HTTP requests are not blocked by a firewall.

Solution

Change the project's Web settings to "IIS Express" instead of "External Host". This is under "Web" under the "Servers" section. Visual Studio should automatically fill in the Project Url.

Click the picture to enlarge.





Explanation

When a project's Web settings are set to an external server, Visual Studio will try to connect to that server to debug the project. This would be used if you were running IIS (not IIS Express) on your local machine and wanted Visual Studio to debug the app running on IIS.

Other things to try

  • Restart Visual Studio, which also restarts IIS Express
  • Run Visual Studio as Administrator.