Performance and security of ASP.NET MVC app - handler mappings and modules

Question

i just have read an interesting article. Basically it says, you should fine-tune IIS settings for every application in 2 ways:

1. handler mappings - remove all unused by application
2. modules - remove all unused by application

Well, i develop ASP.NET for some time now, even at work, and we never ever have done this on production environment afaik. I understand the theoretical advantages presented - minimizing "surface" of application (security), and improving performance. But I am really curious, if you do this in real life (real projects for your customers, not proof-of-concept projects). What are the downsides of this (maintanability maybe?). And most important question - is it worth it ? Is, for example, the performance gain even visible ?

In addition, if you consider this a good practice, please present some good and consistent way (or point me to tutorial), how exactly you do this process - how you decide what stay and what to remove.

For example, what is minimal but working set for ASP.NET MVC 3 application, which uses custom authentication (session based, not relying on Forms auth, Windows auth etc.), no webservices and similar features ?

EDIT

I have found this article : http://madskristensen.net/post/Remove-default-HTTP-modules-in-ASPNET.aspx

In it, Scott Guthrie says:

In general you can get some very small performance wins using this approach - although I'd probably recommend not doing it. The reason is that some features of ASP.NET (forms auth, roles, caching, etc) will of course stop working once you remove the modules they depend on. Trying to figure out why this has happened can often be confusing.

But still no measurments, practices (i am not really convinced by "you can be surprised later" argument :)

Answer 1

<modules runAllManagedModulesForAllRequests="false">
  <!-- disable authorization section -->
  <remove name="UrlAuthorization" />
  <!-- disable unused authentication schemes -->
  <remove name="WindowsAuthentication" />
  <remove name="PassportAuthentication" />
  <!-- disable ACL file and directory check -->
  <!-- <remove name="FileAuthorization" /> -->
  <!-- We don't use ASP.NET Profiles -->
  <remove name="Profile" />
  <!-- We don't provide any WCF service -->
  <remove name="ServiceModel" />
  <!-- Remove modules not used by ASP.NET MVC + jQuery -->
  <remove name="ScriptModule-4.0" />
</modules>

Answer 2

For what's it worth, Security Best Practices for IIS 8 has this:

• Install only the IIS modules you need.

  IIS 8 is composed of more than 40 modules, which allow you to add modules you need and remove any modules you don't need. If you install only the modules you need, you reduce the surface area that is exposed to potential attacks.

• Periodically remove unused or unwanted modules and handlers.

  Look for modules and handlers that you no longer use and remove them from your IIS installation. Strive to keep your IIS surface area as small as possible.

IIS Modules Overview also has IIS modules reference with a section called ' Potential issues when removing this module ' for each module. For example, if DefaultAuthentication module is removed:

Some ASP.NET features may not work for anonymous requests if ASP.NET authentication mode is Forms. Also, DefaultAuthentication.OnAuthenticate event will not be raised.

Answer 3

This doesn't directly answer your question, but in answering another question on SO , I just found out about the performance impacts to MVC of having the URL Rewrite module turned on .

When performing URL generation (for example via a method like Html.ActionLink) in some cases MVC checks to see if the currently requested URL has been rewritten by the URL Rewrite module. If that is the case the result is processed so that it correctly matches the URL requested by the client. The act of checking if a URL has been rewritten has a non-trivial cost (because it involves checking server variables). ASP.NET MVC 3 checks to see if URL Rewrite is turned off and can cache that fact thus avoiding the need to inspect server variables for each request. If URL Rewrite is turned on MVC will have to check server variables even if no rewriting happened for a particular request so if you are not using URL Rewrite you should turn it off.

So here is a case of even if you are not using a module, it can have impacts on your application.

However, I would think that unless you have security concerns with specific modules or handlers that I would have to agree with Scott Gu, you probably are not going to notice (unless you are handling ~1million request per day or something) and would be better served to spend this time tuning your cache (database and content) profiles.

Oh, and so I somewhat answer your question, no we do not do this.

Answer 4

From a performance point of view, that is a great best practice. Often though, there are other factors to be considered.

1. Most applications get expanded over time. If you're not using a feature now, you might in the future. When you do, I can imagine someone forgetting to reconfigure the IIS settings, causing your production environment to be down longer.

2. Production environments are often not in the hands of developers.

   a. The persons who are, probably have enough on their minds to be applying trivial performance tweaks.

   b. The shorter the release manual, the better. Adding unnecessary (in this case, trivial) steps for performance tweaks can lead to steps being looked over.

Again, from a performance point of view it is a great best practice. In my experience, most applications don't require these kind of performance tweaks. Thus, the disadvantages outweigh the advantages. But, like Tommy said, if your application handles millions of requests a day, then every bit helps.

Answer 5

First, I'll be honest here, and be clear that I haven't done this but in one occasion (more on it below).

You have to consider that from a security point of view it is a no brainer. If you know you are Not using a set of features, why keep exposing them?

Now let's go back in time to Sept 2010. There was a serious vulnerability: the asp.net padding oracle. I have a few blog posts on it, one on asp.net padding oracle: impact on asp.net MVC and PHP

Notice how this could affect PHP even if asp.net wasn't actively used.

So the issue was on handlers that are Not typically used in asp.net MVC. In fact, on a few clients servers/applications I was handling at the time, we disabled the offending handlers. Vulnerability closed, before MS rolled out their solution; applications were not affected as we weren't using any of the handlers.

The trade off, is that not all handlers are as simple as that. It can definitely be very hard to know which handlers are in used in some applications. On the other hand, it's good to know what's going on with the pieces of asp.net you're using.