There are quite a few blogs that describe how to remove the common headers sent to the browser by ASP.NET and IIS. Here’s an example from the iis.net website:
As you can see, the headers give away which web server and technology is running the website. To be honest, I’m not entirely sure why IIS or ASP.NET should send these headers in the first place, but it never bothered me all these years till now. Apparently, some security specialists consider this a threat, because potential hackers might exploit this knowledge to execute known security hacks. I was puzzled by this claim, because I think that removing these headers will be of little help to prevent such exploits. For example, in ASP.NET it’s enough to see the ‘.aspx’ in the url to know that it’s ASP.NET (and therefore, IIS). You’d have to use Routing to overcome this, which means that either you should have thought of this prior to development, or you have lots of work to do now (strange enough, the security specialists do not necessarily require this change.) Other examples for detecting which technology is used even without having those headers sent over, come from the actual content downloaded from the server, which can be easily viewed using browser development tools. Here are several examples: Microsoft uses a lot of ‘.axd’ files for web resources; the html rendered from ASP.NET usually has a __VIEWSTATE hidden field; web sites which use ASP.NET themes render style sheets from the App_Themes folder.
Having said that, I looked for information on how to remove those headers. It seems like those three headers, X-Powered-By, X-AspNet-Version and Server, are controlled in entirely different locations. As there are quite a few blogs about this topic, I’ll be happy to simply refer to an excellent blog post, which explains how to remove most headers. However, the reason I’m writing this blog is not because I wanted to provide this url, its because it took me some time to remove the Server header from an IIS 7 running an application pool in Classic mode. For Integrated mode, this can be done via code. But this doesn’t seem to work for Classic app pools. So how do we remove the Server tag in such cases?
I preferred a programmatical solution that would not force a change in IIS configuration. Unfortunately, all my coding attempts failed to remove the Server tag in IIS7 Classic mode. In order to accomplish this, I had to download and install a utility from MS, UrlScan. UrlScan version 3.1 supports IIS7 so it provided a working solution. Although it lacks a graphical interface, setup was quite easy:
- Start->Run->inetsrv and hit enter.
- After installation, there should be a UrlScan folder. Go there.
- Edit the urlscan.ini file. If there isn’t one, you can download one from here.
- Depending on your need:
- Set RemoveServerHeader=1 to remove the Server header completely.
- Set AlternateServerName to a string of your choice to change the header sent over.
One side effect I had was that all of a sudden, the browser requests for css files returned a 403 forbidden code. I wasn’t sure why this happened, but it was obviously the result of installing the UrlScan. I found that AllowDotInPath was set to 0 and that this was the cause of it. I changed it quickly to ‘1’ and the problem was solved. No other problems have arisen so far.
You can also read the full UrlScan reference here
I Came, I Learned, I Blogged 