Removing Unused HTTP Handlers for Better Performance & Security - asp.net

Where can I get a list of what all of the default IIS HTTP handlers do? I need documentation!! I have read a few blogs which recommend removing dozens of unused HTTP handlers for performance and security reasons.
E.g. Removing the TraceHandler-Integrated and TraceHandler-Integrated-4.0 is recommended because otherwise navigating to /trace.axd causes a 500 Internal Server Error instead of a 404 Not Found and you should not have tracing on, in a production environment.
Some of the HTTP handlers that a GitHub project (Now Deleted) recommends removing a huge list manually:
<system.webServer>
<handlers>
<remove name="TraceHandler-Integrated-4.0" />
<remove name="TraceHandler-Integrated" />
<remove name="AssemblyResourceLoader-Integrated-4.0" />
<remove name="AssemblyResourceLoader-Integrated" />
<remove name="WebAdminHandler-Integrated-4.0" />
<remove name="WebAdminHandler-Integrated" />
<remove name="HttpRemotingHandlerFactory-soap-ISAPI-2.0-64" />
<remove name="svc-ISAPI-4.0_32bit" />
<remove name="ScriptHandlerFactoryAppServices-Integrated-4.0" />
<remove name="ScriptResourceIntegrated-4.0" />
<remove name="svc-ISAPI-4.0_64bit" />
<remove name="svc-Integrated-4.0" />
<remove name="vbhtm-ISAPI-4.0_32bit" />
<remove name="vbhtm-ISAPI-4.0_64bit" />
<remove name="vbhtm-Integrated-4.0" />
<remove name="vbhtml-ISAPI-4.0_32bit" />
<remove name="vbhtml-ISAPI-4.0_64bit" />
<remove name="vbhtml-Integrated-4.0" />
<remove name="xamlx-ISAPI-4.0_32bit" />
<remove name="xamlx-ISAPI-4.0_64bit" />
<remove name="xamlx-Integrated-4.0" />
<remove name="xoml-ISAPI-4.0_32bit" />
<remove name="xoml-ISAPI-4.0_64bit" />
<remove name="xoml-Integrated-4.0" />
<remove name="HttpRemotingHandlerFactory-rem-Integrated-4.0" />
<remove name="HttpRemotingHandlerFactory-rem-ISAPI-2.0" />
<remove name="rules-ISAPI-4.0_32bit" />
<remove name="rules-Integrated-4.0" />
<remove name="HttpRemotingHandlerFactory-soap-Integrated" />
<remove name="HttpRemotingHandlerFactory-soap-ISAPI-2.0" />
<remove name="HttpRemotingHandlerFactory-soap-ISAPI-4.0_64bit" />
<remove name="HttpRemotingHandlerFactory-soap-Integrated-4.0" />
<remove name="HttpRemotingHandlerFactory-soap-ISAPI-4.0_32bit" />
<remove name="rules-ISAPI-4.0_64bit" />
<remove name="HttpRemotingHandlerFactory-rem-ISAPI-2.0-64" />
<remove name="HttpRemotingHandlerFactory-rem-Integrated" />
<remove name="HttpRemotingHandlerFactory-rem-ISAPI-4.0_32bit" />
<remove name="HttpRemotingHandlerFactory-rem-ISAPI-4.0_64bit" />
<remove name="AXD-ISAPI-2.0-64" />
<remove name="cshtml-ISAPI-4.0_64bit" />
<remove name="cshtml-Integrated-4.0" />
<remove name="cshtm-Integrated-4.0" />
<remove name="cshtml-ISAPI-4.0_32bit" />
<remove name="cshtm-ISAPI-4.0_64bit" />
<remove name="cshtm-ISAPI-4.0_32bit" />
<remove name="AXD-ISAPI-4.0_64bit" />
<remove name="AXD-ISAPI-2.0" />
<remove name="AXD-ISAPI-4.0_32bit" />
<remove name="PageHandlerFactory-ISAPI-2.0-64" />
<remove name="PageHandlerFactory-ISAPI-2.0" />
<remove name="PageHandlerFactory-ISAPI-4.0_64bit" />
<remove name="PageHandlerFactory-ISAPI-4.0_32bit" />
<remove name="aspq-ISAPI-4.0_64bit" />
<remove name="aspq-Integrated-4.0" />
<remove name="WebServiceHandlerFactory-ISAPI-2.0" />
<remove name="aspq-ISAPI-4.0_32bit" />
<remove name="WebServiceHandlerFactory-Integrated-4.0" />
<remove name="WebServiceHandlerFactory-Integrated" />
<remove name="SimpleHandlerFactory-ISAPI-4.0_64bit" />
<remove name="SimpleHandlerFactory-Integrated-4.0" />
<remove name="SimpleHandlerFactory-Integrated" />
<remove name="SimpleHandlerFactory-ISAPI-2.0" />
<remove name="SimpleHandlerFactory-ISAPI-2.0-64" />
<remove name="WebServiceHandlerFactory-ISAPI-4.0_32bit" />
<remove name="WebServiceHandlerFactory-ISAPI-4.0_64bit" />
<remove name="WebServiceHandlerFactory-ISAPI-2.0-64" />
<remove name="SimpleHandlerFactory-ISAPI-4.0_32bit" />
<remove name="ISAPI-dll" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
</handlers>
</system.webServer>

If you really want a minimal set of handler mappings, I suggest you start clean, in your web.config remove all handlers and just use the StaticFile one:
<system.webServer>
<handlers>
<clear />
<add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
Now add all the handlers you need back in, just for the bitness and mode you're running in.
For a basic MVC project it may be enough to add
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />
What do all the handlers do?
I couldn't find any documentation either, so here's my attempt:
The handler mappings are defined in %SystemRoot%\System32\inetsrv\config\applicationHost.config - system.webServer/handlers
In my case there were 87 mappings.
50 of them are modules="IsapiModule" scriptProcessor="...aspnet_isapi.dll" for ASP.NET. These cover all the various asp.net extentions and may exist for CLR versions 2.0 and 4.0 and for 32bit and 64bit. Most of them are for Classic Mode.
They usually handle the following extensions:
*. = ExtensionlessUrlHandler-ISAPI
*.ashx = SimpleHandlerFactory-ISAPI
*.asmx = WebServiceHandlerFactory-ISAPI
*.aspq = aspq-ISAPI
*.aspx = PageHandlerFactory
*.axd = AXD-ISAPI
*.cshtm = cshtm-ISAPI
*.cshtml = cshtml-ISAPI
*.rem = HttpRemotingHandlerFactory-rem-ISAPI
*.rules = rules-ISAPI
*.soap = HttpRemotingHandlerFactory-soap
*.svc = svc-ISAPI
*.vbhtm = vbhtm-ISAPI
*.vbhtml = vbhtml-ISAPI
*.xamlx = xamlx-ISAPI
*.xoml = xoml-ISAPI
If your project doesn't use certain extensions, you may remove these handlers.
Most handler mappings have a preCondition like apply in 32bit ApplicationPools, or when in Classic Mode. If you only ever run 64Big integrated mode, you can remove all classic mode and 32bit handler mappings.
If we look at *.cshtml for a Razor view file, you will find three mappings, two for ClassicMode in 32/64 bit which point to the ASP.NET ISAPI modules, but the third applies only in integrated mode and maps to HttpForbiddenHandler, because the MVC routing works differently in Integrated Mode and you never want to allow access to view files directly.
There may be IsapiModules for classic asp or CGI, like the ASP.NET mapping there are there to handle the requests for files with certain extensions.
The second biggest group are the type="System. handlers, lets look at them:
System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory
Handles *.rem and *.soap files in integrated mode. Can be removed if you are not using remoting.
System.ServiceModel.Activation.HttpHandler, System.ServiceModel.Activation
Handles certain WCF requests with *.rules,*.xoml,*.svc extensions.
System.Web.Handlers.AssemblyResourceLoader
Handles WebResource.axd requests, these may be used in WebForms, but usually not in MVC projects.
System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions
For handling ScriptResource.axd which provides JavaScript and CSS resources in WebForms.
System.Web.Handlers.TraceHandler
Handler for trace.axd to display ASP.NET trace information. On a production site, you want to remove this handler.
System.Web.Handlers.TransferRequestHandler
Used to handle extensionless requests in integrated mode. This forwards the request to the routing engine to decide how to handle these requests. More Info
System.Web.Handlers.WebAdminHandler
Handles WebAdmin.axd to display the ASP.NET Website Administration Toolkit, you can remove this if you don't use that builtin feature.
System.Web.HttpForbiddenHandler
Allows us to prevent access to any files with certain extensions. However it returns a 500 HTTP status and actually throws a System.Web.HttpException exception on the server.
In my opinion there are better ways to blog certain extensions such as IIS Request Filtering.
System.Web.HttpMethodNotAllowedHandler
I think this one is no longer used in modern IIS, it returns a 405 HTTP status and also throws and HttpException
System.Web.HttpNotFoundHandler
Also, not longer in my current configuration. It throws a 404 HTTP exception.
System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions
Handles *.asmx and *_AppService.axd to support Web service calls via Ajax.
System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services
Also handles *.asmx web service requests in integrated mode for DOT.NET 2
System.Web.StaticFileHandler
Returns a static file, no longer used?
System.Web.UI.PageHandlerFactory
Handles ASP.NET WebForm pages .aspx in integrated mode.
System.Web.UI.SimpleHandlerFactory
Handles ASP.NET custom handlers .ashx in integrated mode.
System.Xaml.Hosting.XamlHttpHandlerFactory, System.Xaml.Hosting
Handles Windows Workflow Foundation services .xamlx in integrated mode.
more handlers:
modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule"
This is usually the very last mapping to handle any requests that has not been handled by any of the previous handles path="*" verb="*". It actually uses three different modules. The StaticFileMode one looks for a physical file matching the requested URL, if not found, the DefaultDocumentModule looks for a default document in the same folder as the requested URL and if that is also not found, the DirectoryListingModule may display the content of the directory if enabled.
modules="ProtocolSupportModule"
This handles all requests for the HTTP verbs TRACE and OPTIONS, if you remove this mapping, all trace and options request will return a "405 Method not allowed"

Answer to this:
Where can I get a list of that all of the default IIS HTTP handlers do?
Open IIS, CMD-->inetmgr, then click handler mappings, see below screenshot.
Click that, it will show you all default enabled HTTP handlers for that web server.
Note: When you select a virtual directory and then do this process, i.e. click handler mappings, and remove one of mapping, it will add that line in web.config.
E.g. I have removed aspq-ISAPI-4.0_64bit, so it has changed web.config for that virtual directory, i.e. it has added following line to web.config.
<remove name="aspq-ISAPI-4.0_64bit" /> under system.webServer\handlers.
Update : This handlers are invoked when particular file type request come, until then it sits idle. So there won't be any performance issue for these handlers.
Example, that you have removing handler for *.axd will improve security, my answer to this, some DLL might need those files for rendering js and css, and if you remove that, it will not work. E.g. - HTTP Handler cannot find axd file in nested web application folder: Telerik RadScriptManager cannot find WebResource.axd in ~/admin/ folder

I'm running in the same question last week and after a lot of research, I think that I found something similar in GitHub:
List of "insecure handlers": https://gist.github.com/marcbarry/47644b4a43fbfb63ef54

Related

ASP.NET Core with IIS - HTTP Verb Not Allowed

We have an ASP.NET Core 2.0 web site that also presents a couple of simple Web API methods for UI enhancement purposes.
The Web API calls work as expected when running locally under IIS Express, but when we deploy to our IIS 8.5 production web server, we get the following error when making HTTP DELETE and PUT requests...
405 Method Not Allowed
After some web searching, we have found several posts suggesting the removal of the IIS WebDAV module. We have disabled this in IIS (it is our server), and we have also tried the following:
Disabled WebDAV
Enabled WebDev and set Allow verb filtering = False
Set the Hander Mappings to allow All Verbs in the Request Restrictions settings for: aspNetCore, WebDAV and ExtensionlessUrlHandler-Integrated-4.0
None of the above steps have resolved our problem.
Any advice/direction would be much appreciated.
This was what worked for me (netcore 2.0)
<system.webServer>
<modules runAllManagedModulesForAllRequests="false">
<remove name="WebDAVModule" />
</modules>
</system.webServer>
Found here: https://www.ryadel.com/en/error-405-methods-not-allowed-asp-net-core-put-delete-requests/
After hours of research and trial and error, the fix seems to be pretty simple. Add a Web.config file to your .NET Core 2.0 application:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!-- To customize the asp.net core module uncomment and edit the following section.
For more info see https://go.microsoft.com/fwlink/?linkid=838655 -->
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="aspNetCore" />
<remove name="WebDAV" />
<!-- I removed the following handlers too, but these
can probably be ignored for most installations -->
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="aspNetCore"
path="*"
verb="*"
modules="AspNetCoreModule"
resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%"
arguments="%LAUNCHER_ARGS%"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
Hope this helps.
Whilst removing WebDAV may solve your issue, you may be wondering (like I was), what is WebDAV and what is it used for?
I found this page which helps explain it:
https://www.cloudwards.net/what-is-webdav/
To prevent WebDav from getting enabled at all, remove the following entry from the ApplicationHost.config:
<add name="WebDAVModule" />
The entry is located in the modules section.
Exact location of the config:
C:\Windows\System32\inetsrv\config\applicationHost.config
This worked well for me in .Net Core 2.1
In my case, I got the 405 error for .Net 5 Web API PUT and DELETE calls. I tried multiple solutions like removing WebDAV (Turn Windows features on or off -> IIS -> World Wide Web Services -> Common HTTP feature -> WebDAV Publishing) doesn't work, editing WebDAV entry in "Handler Mappings" messed up the application.
Solution
In IIS, select the application
Add rules to allow HTTP verbs in Request Filtering (But this alone doesn't work).
Go to "Modules", then select the "WebDAV Publishing" module and remove it.
Go to "Handler Mappings", then select the "WebDAV" and remove it.
in cmd run IISRESET
Add the following lines to your web.config file. That does it.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,PUT,DELETE,DEBUG" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\Ftms.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
Remove the WebDAV Publishing from IIS server. Its come under the Internet Infromation service -> Common Http Features
https://ignas.me/tech/405-method-not-allowed-iis/
In my case, I resolved the issue after I add requireAccess="None" to aspNetCore handler
Like this :
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" requireAccess="None" />
For me, I resolved the issue after I noticed I was trying to post to the client domain instead of the API. [facepalm]
I didn't even have a mapping for aspnetcore under Handler Mappings in IIS. It made me open Visual Studio Installer and install Development time IIS support under .NET cross-platform development. Then, the aspnetcore handler mapping showed up in IIS.
If you're developing with recent ASP.NET Core version and using development server it's likely that it's not a WebDAV issue at all.
Make sure that your routes and HttpDelete/HttpPut attributes are set correctly. Otherwise you'll get the same or similar errors if the method is simply mismatched (e.g. route to a HttpGet one was chosen).
After long research on the internet, I solved it as follows;
<configuration>
<system.webServer>
<modules>
<remove name="ModSecurity IIS (64bits)" />
<remove name="ModSecurity IIS (32bits)" />
</modules>
</system.webServer>
To prevent WebDav from getting enabled at all, remove or comment the following entry from the ApplicationHost.config:
<add name="WebDAVModule" />
The entry is located in the modules section.
Exact location of the config:
C:\Windows\System32\inetsrv\config\applicationHost.config
This worked well for me in .Net Core 2.2

SiteMinder SSO not protecting ASP.NET MVC 5 site

This problem may be related to the UrlRoutingModule handling all the routing and bypassing SiteMinder. Any ideas on how may I be able to make SiteMinder's webagent handle the HTTP request before MVC's default request handler?
<system.webServer>
<!-- SM Server Config -->
<validation validateIntegratedModeConfiguration="false" />
<handlers>
<add name="wa-handler" path="*" verb="*" type="" modules="IsapiModule" scriptProcessor="%NETE_WA_PATH%\ISAPI6WebAgent.dll"
resourceType="Unspecified" requireAccess="None" allowPathInfo="false" preCondition="" responseBufferLimit="4194304" />
</handlers>
<modules>
<remove name="FormsAuthentication" />
</modules>
</system.webServer>
Issue Resolved: Apparently, for SiteMinder to protect ASP.NET MVC Apps, it must be upgraded to version R12.5 / WebAgent 7 or higher. Just update SiteMinder on your IIS server and it should start working.

How to disable or remove DirectoryListingModule in IIS to prevent HTTP 405 error

I've written an ASP.Net web app with a custom HTTP handler. However, after importing the app into IIS 7.5, IIS returns this when the app is invoked:
HTTP/1.1 405 Method Not Allowed
When I enable the Failed Request Tracing Rules feature to trap HTTP 405 errors I see this:
My handler does not get invoked. So I'd like to remove the DirectoryListingModule. But, similar to #Brendan Hill here, nothing I've tried seems to disable the module. Even commenting out all the lines that mention this module in C:\Windows\System32\inetsrv\Config\applicationHost.config doesn't work:
<!--add name="DirectoryListingModule" image="%windir%\System32\inetsrv\dirlist.dll" /-->
<!--add name="DirectoryListingModule" lockItem="true" /-->
<!--add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" /-->
Like #Brendan Hill I would prefer a solution in my app's Web.config so I don't have to fiddle with IIS's settings. Excerpt from my current Web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="AuthServiceHandler"
path="*."
verb="*"
type="AuthServiceHTTPHandler.App_Code.AuthServiceHandler"
preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
If I import my app into the Default Web Site in IIS and bind it to 9000 I can invoke the app with a POST request to http://localhost:9000 . This URL is fine; I'm not trying to request any web pages.
In the end I worked around the problem by creating a dummy web page and binding the handler to that for the POST verb I was interested in:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="AuthServiceHandler"
path="dummy.html"
verb="POST"
type="AuthServiceHTTPHandler.App_Code.AuthServiceHandler"
preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
The handler would then be triggered for calls to http://localhost:9000/Auth/dummy.html, where Auth was the name of my app when deployed under the Default Web Site in IIS. (I hadn't appreciated I needed the context as well when I posted the question above.) So the DirectoryListingModule was effectively bypassed.
Handily, by binding the handler to the POST verb only you can use the same 'dummy' web page to provide useful info for users if they browse to it in a web browser (because the browser sends a GET request which won't be intercepted by the handler).
No IIS settings needed to be changed. This worked for me using IIS 7.5 on Windows 7.

can't get System.Web.SessionState with asp.net 4 webforms routing

I've seen couple of questions here such as State Service when using system.web.routing in WebForms but couldn't find proper solution.
I am using asp.net routing with webforms on iis7. I've added below to webconfig file to get it working at first palace
<system.webServer><modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
</system.webServer>
Problem is that when i use routed pages Session state is not avaliable and i get
Session state can only be used when enableSessionState is set to true, either in a configuration file or in the Page directive. Please also make sure that System.Web.SessionStateModule or a custom session state module is included in the <configuration>\<system.web>\<httpModules> section in the application configuration.
I have sesison state enabled and if i call page itself with aspx extension instead of routed url everything works fine.
Anyone know how to get session state work with routing?
got it! see http://www.heartysoft.com/post/2010/07/26/aspnet-routing-iis7-remember-modules.aspx
<system.webServer>
<modules >
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
<remove name="Session"/>
<add name="Session" type="System.Web.SessionState.SessionStateModule" preCondition=""/>

How do I protect static files with ASP.NET form authentication on IIS 7.5?

I have a website running on a IIS 7.5 server with ASP.NET 4.0 on a shared host, but in full trust.
The site is a basic "file browser" that allows the visitors to login and have a list of files available to them displayed, and, obviously, download the files. The static files (mostly pdf files) are located in a sub folder on the site called data, e.g. http://example.com/data/...
The site uses ASP.NET form authentication.
My question is: How do I get the ASP.NET engine to handle the requests for the static files in the data folder, so that request for files are authenticated by ASP.NET, and users are not able to deep link to a file and grab files they are not allowed to have?
If you application pool is running in Integrated mode then you can do the following.
Add the following to your top level web.config.
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Now you can use the standard ASP.NET permissions in your web.config to force forms authentication for all files in the directory.
<system.web>
<authorization>
<deny users="?" />
</authorization>
<authentication mode="Forms" />
</system.web>
I had the same problem with getting roles to authenticate. Through trial and error I finally got it to work with a small edit to #Joel Cunningham's code:
<modules runAllManagedModulesForAllRequests="true" >
I used these two sites as references: http://forums.iis.net/t/1177964.aspx and http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis-integrated-pipeline/
This is an old thread, but I happened on it and ran into the same problem as Egil. Here is the version of Joel's fix that includes roles:
<modules runAllManagedModulesForAllRequests="false">
<remove name="FormsAuthenticationModule" />
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
Addendum:
As #eych noted the accepted answer also blocks access to the ~/Content folder (or wherever you have your CSS), and ~/Scripts, and so on.
If you want to allow exceptions -- i.e. allow certain files/folders to be accessible by unauthenticated users -- you can do that by means of the location element. Add the following to web.config:
<location path="Content">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Update:
An alternative solution is to is to leave access on by default -- which will allow access to your CSS / JavaScript / etc. -- and apply the "lock" (only) to the folder where the static content is stored:
<location path="data">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
Caveat: in our case (an MVC site) we needed to decorate all our controller actions (except login) with [AuthorizeAttribute]. Which is a good idea anyway, but had previously not been necessary (because previously any unauthorized request was redirected to the login page).
I wanted to know why it would be required to re-add modules (with default options) that are added by default for the Integrated Pipeline, so I dug a little deeper.
You need to remove and re-add the modules because, by default, the modules aren't added with the default options. They have a precondition added for backwards compatibility to run only for content handled by a registered ASP.NET handler (e.g., .aspx pages).
The default looks like this:
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
preCondition="managedHandler" />
By removing the modules and re-adding them without a precondition, those individual modules run for every request (including your static content). It is more granular than enabling runAllManagedModulesForAllRequests.
You can read about it in a couple articles from when the Integrated Pipeline was introduced with IIS 7:
ASP.NET Integration with IIS 7
How to Take Advantage of the IIS 7.0 Integrated Pipeline
Note that there is a typo or the module name in the second article (and #John's answer) was changed from FormsAuthenticationModule to FormsAuthentication at some point.
The set of working modules in IIS 7.5 thru 8.5 looks like this for me:
<system.webServer>
<modules>
<!-- Re-add auth modules (in their original order) to run for all static and dynamic requests -->
<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
</modules>
</system.webServer>
If you application pool is running in Classic mode, you can do the following. You will have to repeat these steps for each file extension you'd like to handle, but I'm using .html here.
First, add a page build provider to the Web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<compilation>
<buildProviders>
<add type="System.Web.Compilation.PageBuildProvider" extension=".html"/>
</buildProviders>
</compilation>
</system.web>
</configuration>
Then add a page handler factory:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpHandlers>
<add type="System.Web.UI.PageHandlerFactory" path="*.html" verb="*"/>
</httpHandlers>
</system.web>
</configuration>
Then add a page handler:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" name="HtmlHandler-Classic-32" />
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" path="*.html" verb="GET,HEAD,POST,DEBUG" name="HtmlHandler-Classic-64"/>
</handlers>
</system.webServer>
</configuration>
This worked for me. (Credit: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages.)

Resources