Remove Server Response Header IIS 8.0 / 8.5 - iis

How can we remove the server header response in IIS 8.0/8.5?
My current server report:
Microsoft-IIS/8.0
Microsoft-IIS/8.5
For IIS 7.0 I used the URLScan 3.1 however this is only supported for IIS 7.0 and not 8.x

There is another solution and in my opinion this solution is the best and safe.
You can use UrlRewrite module created by the Microsoft. The Url Rewrite module redirects your url and can also change your IIS server name in the response header.
You don't have to use redirect property. You can use just change the Server header value.
Here are the steps:
First, download UrlRewrite module from this link:
http://www.iis.net/downloads/microsoft/url-rewrite and install
it on your IIS server. After that, restart IIS by this command on cmd
console
iisreset /restart
Add the following item to the your web config file under the <system.WebServer> tag. You can write anything to the Value item as server name.
Finally we changed the IIS version name on the data's header. Restart IIS again. via cmd console.
Bonus: If you want to test your website to see if it is working or not... You can use "HttpRequester" mozilla firefox plugin. for this plugin: https://addons.mozilla.org/En-us/firefox/addon/httprequester/
PS: I tested it and it worked for me on the IIS server. Not on the has been created temproray IIS server by the Visual studio.

It is possible now to remove Server header from web.config starting from IIS 10.0 :
<security>
<requestFiltering removeServerHeader ="true" />
</security>
More details on how to remove all unwanted/unnecessary headers can be found here.
Please note that this hides server header from the "application", as do all the other approaches. If you e.g. reach some default page or an error page generated by the IIS itself or ASP.NET outside your application these rules won't apply. So ideally they should be on the root level in IIS and that sill may leave some error responses to the IIS itself.
Note there is a bug in IIS 10 that makes it sometimes show the header even with the modified config prior to 2019.1C. It should be fixed by now, but IIS/Windows has to be updated.

Add the below code in Global.asax.cs:
protected void Application_PreSendRequestHeaders()
{
// Remove the default Server header
Response.Headers.Remove("Server");
// Optionally, add your own Server header
Response.AddHeader("Server", "My-App/1.0");
}
This has been tested to work under IIS 8.5 and 10.0.

Unfortunately most of the recommendations you will find online for removing the "Server" header in IIS will not work for IIS 8.0 and 8.5. I have found the only working option, and in my opinion, also the best, is to use an IIS Native-Code module.
Native-Code modules differ from the more common Managed modules, as they are written using the win32 APIs rather than ASP.NET. This means that they work for all requests (including static pages and images) rather than just requests that past though the ASP.NET pipeline. Using a Native-Code module, it is possible to remove unwanted headers at the very end of the request, meaning that you can remove headers (including the "Server" header) regardless of where they have been set.
Binaries and source code of an example Native-Code module for removing headers in IIS 7.0 to 8.5 are available in the following article.
https://www.dionach.com/en-au/blog/easily-remove-unwanted-http-headers-in-iis-7-0-to-8-5/

Just use clear tag in custom headers segment in web.config:
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-Custom-Name1" value="MyCustomValue1" />
<add name="X-Custom-Name2" value="MyCustomValue2" />
</customHeaders>
</httpProtocol>
</system.webServer>
For dynamic headers, You can use this code in Global.ascx:
protected void Application_PreSendRequestHeaders()
{
Response.Headers.Remove("Server");
Response.AddHeader("Sample1", "Value1");
}

This is dead simple. Just create a custom module:
public class HeaderStripModule : IHttpModule
{
public void Init(HttpApplication application)
{
application.PreSendRequestHeaders += (sender, args) => HttpContext.Current.Response.Headers.Remove("Server");
}
public void Dispose(){}
}
And then register in web.config or applicationHost.config if you want machine wide implementation.
<system.webServer>
<modules>
<add name="HeaderStripModule" type="MyNamespace.HeaderStripModule" />
</modules>
</system.webServer>

URLScan has been discontinued starting from IIS 7.5, since its functionalities are supposed to be available through "request filtering" option (feature added in IIS 7.5).
But the URLScan's 'Remove server header' option does not look like having any equivalent in "request filtering".
As said on this answer and this answer to you question, you can emptied the Server with URLRewrite instead, which remains available on IIS 8/8.5 (with some update required for having its UI in IIS administration console).
It turns out, looking at this blog, that URLScan can still be installed on IIS 8/8.5, if lack of official support is not an issue.
I have not tested myself. Here are the steps:
Install IIS 6 Metabase compatibility (if not already there)
Install Isapi Filters (if not already there)
Install URLScan (from download-able installer, not from web platform installer)
Configure URLScan through its ini file (by default in C:\Windows\System32\inetsrv\urlscan)
Maybe some iisreset or even a reboot should be done. URLScan should be visible in IIS among Isapi filters

In IIS Manager, at the server level, go to the Features view. Click on HTTP Response Headers. You can add/remove headers there. You can also manage the response headers at the site level as well.

Related

HTTP Error 500.19 - IIS and MIME Type not working in windows10?

I am trying to run my asp.net mvc website on the IIS. I got the following error:
HTTP Error 500.19 - Internal Server Error The requested page cannot be
accessed because the related configuration data for the page is
invalid.
I use IIS through IIS manager and when I try to configure MIME Types in IIS Manager, I got the following config error:
There was an error while performing this operation. Error: Cannot add
duplicate collection entry of type 'mimeMap' with unique key attribute
'fileExtension' set to '.woff2'.
As a result of my detailed research, this problem occurs on IIS 7.5. How to get rid of this errors and run my web page on IIS?
At first, try to install iis rewrite module to told IIS my custom web.config is not failure or faulty. If it's not fix the problem, I suggest another solution particularly for your problem. Delete your .wolf2 config from your web.config file. For example;
<staticContent>
<mimeMap fileExtension=".woff2" mimeType="application/font-woff2" />
</staticContent>
Delete mimeMap row which has .woff2 file extension from the staticContent. It would fix your problem because this error says that I already have .wolf2 in my config file but you trying to add one more.

X-Frame-Options not working IIS web.config

Our site is not currently safe from clickjacking, so I went into the web.config and added
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="DENY" />
</customHeaders>
</httpProtocol>
</system.webServer>
This is very straight forward code. My issue is that it's just not working. The questions I have are:
Is there a way for me to see if the X-Frame-Options is in the header response? I looked for it with httpfox and got nothing, so I can't verify if the web.config is actually putting things in the header.
Why is this not working? What can I do to test or move forward?
I did try to add it in the Global.asax in the Application_Start method, but I cant seem to "hit" this method when I debug; it does not hit breakpoints.
private void Application_Start(object sender, EventArgs e)
{
// Code that runs on application startup
HttpContext.Current.Response.AddHeader("x-frame-options", "DENY");
LogHelper.Info("Cost of Care Web Application Starting");
}
I would like to add that I have tried to add it straight into the head tag and I've also tried to add it in a meta tag like so
<meta http-equiv="X-Frame-Options" content="deny">
The X-Frame-Options header can be used to control whether a page can be placed in an IFRAME. Because the Framesniffing technique relies on being able to place the victim site in an IFRAME, a web application can protect itself by sending an appropriate X-Frame-Options header.
To configure IIS to add an X-Frame-Options header to all responses for a given site, follow these steps:
Open Internet Information Services (IIS) Manager.
In the Connections pane on the left side, expand the Sites folder and select the site that you want to protect.
Double-click the HTTP Response Headers icon in the feature list in the middle.
In the Actions pane on the right side, click Add.
In the dialog box that appears, type X-Frame-Options in the Name field and type SAMEORIGIN or DENY in the Value field.
Click OK to save your changes.
Since my comments answered the question here's the end result:
For some reason setting the X-Frame-Options in web.config doesn't seem to actually work even though the documentation makes it sound like it should.
An easy work around is to set the headers manually using:
Response.AddHeader("X-Frame-Options", "DENY");
If you need this set for every request with no exceptions you can add the Application_BeginRequest to Global.asax:
protected void Application_BeginRequest()
{
Response.AddHeader("X-Frame-Options", "DENY");
}
The answer of siva.k does not work in connection with MVC5 as the header is generated twice here. The following code should work:
protected void Application_Start()
{
// MVC5 generates the "X-Frame-Options SAMEORIGIN" header by default, the following line disables the default behaviour
System.Web.Helpers.AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
}
protected void Application_BeginRequest()
{
Response.AddHeader("X-Frame-Options", "DENY");
}
The SuppressXFrameOptionsHeader flag was mentioned here: https://stackoverflow.com/a/20262211/3936440
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src: https:; frame-ancestors 'self' X-Frame-Options: SAMEORIGIN" />
</customHeaders>
</httpProtocol>
</system.webServer>
Your web.config entry needs to be under content security policy to make use of current coding not previously depreciated. The value under content security policy of value="default-src: https: is unique to your website.
The content that matters is what comes after 'value="default-src: https:' but most importantly is contained within Content Security Policy.
Here is another thing to consider:
If you have a separate back-end and UI projects (as is very common for REST based sites), make sure that you put X-Frame-Options in the UI web.config. Your API is probably allowing cross site calls so adding the header to your API project would make no sense.
I found that some file types (.asp and .htm files) were getting the X-Frame-Options header added by this mechanism and others (.js) weren't. Using the IIS Admin utility I removed the header from the application level and added it at the server level, and then all files were getting the header added.

Microsoft.Owin.StaticFiles works in console host but I get a 404 in IIS on file requests

I have Microsoft.Owin.FileServer (v2.1.0) set up in my Owin pipeline, and setting up FileServerOptions with EnableDirectoryBrowsing = true works great for showing the directory contents in both my console host and iisexpress.
It's when I try to view a particular file (so, the StaticFiles part) I have problems in iisexpress. Still works great in the console host, but in iisexpress I get a 404:
HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Most likely causes:
- The directory or file specified does not exist on the Web server.
- The URL contains a typographical error.
- A custom filter or module, such as URLScan, restricts access to the file.
I do have the latest Microsoft.Owin.Host.SystemWeb referenced in the web host.
Adding <modules runAllManagedModulesForAllRequests="true"> didn't work for me (VS2013, IIS Express).
Forcing all requests to use the Owin pipeline did:
(in web.config)
<configuration>
<system.webServer>
<handlers>
<add name="Owin" verb="" path="*" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb"/>
</handlers>
</system.webServer>
</configuration>
I had to add the following setting:
<modules runAllManagedModulesForAllRequests="true">
to get the module that Microsoft.Owin.Host.SystemWeb automatically registers to run for routes like *.txt, *.js that IIS was assuming were static files to run through the Owin pipeline.
This setting does have performance implications for actual static files, but this works for me.
I've just struggled with this for the last couple of hours, adding the handler below did work however I don't believe this was the correct approach, it caused public void Configuration(IAppBuilder appBuilder) to be invoked twice.
<add name="Owin" verb="" path="*" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb"/>
I did some reading and found https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-middleware-in-the-iis-integrated-pipeline
which then lead me to use UseStageMarked().
So now my call to UseStaticFiles() is followed by a called to UseStageMarker() like so:
appBuilder.UseStaticFiles();
//allows owin middlwares to be executed earlier on in the pipeline.
appBuilder.UseStageMarker(PipelineStage.Authenticate);
There is a very good read on it here:
You can find UseStageMarker inside the Microsoft.Owin package here: https://www.nuget.org/packages/Microsoft.Owin/
I hope this helps someone else.
Thanks
Steve

ColdFusion 11 installation unsuccessful

I installed ColdFusion 11 Developer version (downloaded from Adobe site 3 months trial) on Windows 8.1 and IIS7. I got this error when trying to open the ColdFusion administrator (see below). Is there a step by step example on how to fix this?
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Detailed Error Information:
Module CustomErrorModule
Notification SendResponse
Handler cfmHandler
Error Code 0x800700b7
Config Error Cannot add duplicate collection entry of type 'mimeMap' with unique key attribute 'fileExtension' set to '.air'
Config File \localhost\?\C:\inetpub\wwwroot\web.config
Requested URL localhost:80/administrator/CFIDE/index.cfm
Physical Path C:\inetpub\wwwroot\administrator\CFIDE\index.cfm
Logon Method Anonymous
Logon User Anonymous
Config Source:
4: <staticContent>
5: <mimeMap fileExtension=".air" mimeType="application/vnd.adobe.air-
application-installer-package+zip" />
6: </staticContent>
Remove the MIME type from web.config
<mimeMap fileExtension=".air" mimeType="application/vnd.adobe.air-application-installer-package+zip" /> and save the file. Restart IIS and that should fix the issue.
This happened to me as well after updating Coldfusion 11 to the upgrade 2 (patch),
somehow it reads web.config file under C:\Coldfusion11\cfusion\wwwroot
What I did was simply rename the web.config to something like web - error.config
IIS will skip this file and run just fine.
When the file exists, I couldn't even access MIME configuration from the IIS Manager, so removal or rename of that file was the solution for me.
It's also discussed in : http://blog.immanuelnoel.com/2014/09/22/busting-the-http-error-500-19-on-coldfusion-11-iis/ and probably a bug under initial coldfusion configuration.
Removing the mime type from the web.config was enough and its remaining content was all right in our case; please note that this was related to the ColdFusion sites in general and not with the ColdFusion Administrator. The problem started after upgrading from ColdFusion 10 (update level 11) to 11 (update level 0) (on IIS 7.5, Windows Server 2008 R2), having changed the connectors from old version to ColdFusion 11 (as the installation document indicates at "Verify your IIS configuration" section). It had two positive effects:
the cascading styles started being delivered correctly
the 500 Internal Error on the IIS "Windows Authentication" directories stopped appearing (we regarded also https://forums.adobe.com/thread/1031711)
Was it an upgrade? I had a similar problem. I had to manually disable my Coldfusion 9 handlers.
If your previous Coldfusion handlers are still active, and you don't want to remove them until you are confident 11 is stable you can deactivate them in the web.config file.
<handler>
<remove name="AboMapperCustom-somenumber" />
<remove name="AboMapperCustom-anothernumber" />
</handler>
The web.config file should be found in the root directory of each website.

iisnode - IIS7.5: 405 Method not allowed when performing PUT request

I started to do some experimentation with iisnode and expressjs to create a REST like API with node.
So on the server.js I created something like
app.put("/test", function(req, res){
...
});
However, when I execute the PUT request I get a 405 Method not allowed from the IIS 7.5 installation.
Any idea on how to solve this?
BTW, I googled already and tried to add the PUT verbs here and there in the different Handler Mappings with no success...
I now finally found the solution to this problem namely the WebDavModule was blocking my PUT requests.
To resolve the issue:
Open your IIS Manager
Goto your application configuration and open "Modules"
Search WebDavModule and remove it (menu on the right)
It then worked for me.
Alternatively, in your application's web.config add
<system.webServer>
...
<modules>
<remove name="WebDAVModule"/>
</modules>
</system.webServer>
One reason may be that your web.config does not map the particular request you are making to the iisnode handler. In that case the request is picked up by the static request handler which does not support PUT methods and responds with a 405.
To fix this you need a iisnode handler registration like this in your web.config: https://github.com/tjanczuk/iisnode/blob/master/src/samples/helloworld/web.config#L7
In addition, if you plan to use URL that do not end with the name of your node.js file (like seems to be the case above), you will need to use a URL rewrite module to tell IIS exactly which requests should have their URLs rewritten to point to the URL of your node.js entry point. Read more at: http://tomasz.janczuk.org/2011/08/using-url-rewriting-with-nodejs.html

Resources