It's considered good practice to remove the version number headers commonly emitted by IIS and ASP.NET applications, you've probably seen these before:

Server: Microsoft-IIS/8.0
X-AspNetMvc-Version: 3.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET

NWebsec helps you suppress almost all of these version headers, i.e. all but the Server: Microsoft-IIS/8.0 header.

NWebsec.Mvc will disable the MVC version header programatically (through a PreApplicationStartMethodAttribute).

The NWebsec package will add the following to your web.config to get rid of the AspNet version header:

<system.web>
  <httpRuntime enableVersionHeader="false"/>
</system.web>

The X-Powered-By: ASP.NET header is actually added by the IIS itself. Unfortunately, it doesn't exist in the header collection when any of the ASP.NET events fire in the processing pipeline. To get rid of the X-Powered-By: ASP.NET header, NWebsec will add the following to your web.config. This will clear the list of headers added by IIS (except the Server header).

<configuration>
   <system.webServer>
      <httpProtocol>
         <customHeaders>
            <clear />
         </customHeaders>
      </httpProtocol>
   </system.webServer>
</configuration>

Unfortunately, NWebsec no longer removes the "Server" header as of version 3.0. The "Server" header is added by IIS, and can only be removed by an ASP.NET application in the PreSendRequestHeaders event. However, in mid 2012 Microsoft published new guidance on What not to do in ASP.NET, and what to do instead, instructing developers to not use the PreSendRequestHeaders event.

Prior to version 3, NWebsec did its work in the PreSendRequestHeaders event. From version 3, NWebsec uses different events to set headers to avoid issues with async requests. Consequently, the "Server header" can no longer be removed by NWebsec.

Note that removing the "Server" header primarily saves you some bandwith, it's not that much of a security improvement. You can use a variety of fingerprinting techniques to detect the IIS version, see e.g. Fingerprinting IIS.

If you're determined to remove the header, there are a few ways you can go about it.
  • If you have a load balancer/reverse proxy, it might be able to remove the "Server" header for you.
  • You can install UrlScan on each web server to get rid of the "Server" header. For instructions on how to do it by hand, go read Shhh… don’t let your response headers talk too loudly.
Good luck!
-

Last edited Jan 4 at 9:03 PM by klings, version 13

Comments

klings May 21 at 9:54 PM 
Thank you for leaving a comment!

Yes I could probably use these events to reintroduce the feature, but I'm a bit reluctant to introduce features that require a very specific framework version. Where NWebsec is now, I can build the libraries for .NET version 3.5 through 4.5.2. This is important, as there are a lot of applications out there still running on the older framework versions. Introducing code that is framework version specific means a more complicated code base, which translates to a higher maintenance cost over time. As I'm developing this library in my spare time, I try to keep the maintenance cost as low as possible.

The funny thing is, in the last release I completed a full redesign of the internals of NWebsec which was necessary after MSFT deprecated the PreSendRequestHeaders event. Excellent timing that they now introduced those new methods. :)

As for the feature itself, removing the server header, I don't regard it as very important. As mentioned in the docs here, there are other ways to figure out the IIS version. There are a few updates to NWebsec on the way that are much more important, so I'd rather spend my time on those.

reidcs May 15 at 10:08 AM 
Can this feature be brought back now ? I note in the release notest for .NET 4.5.2

"New HttpResponse.AddOnSendingHeaders and HttpResponseBase.AddOnSendingHeaders methods are more reliable and efficient than HttpApplication.PreSendRequestContent and HttpApplication.PreSendRequestHeaders. These APIs let you inspect and modify response headers and status codes as the HTTP response is being flushed to the client application. These reliability improvements minimize deadlocks and crashes between IIS and ASP.NET."

http://blogs.msdn.com/b/dotnet/archive/2014/05/05/announcing-the-net-framework-4-5-2-release.aspx

Perhaps you can make use of these new events?