Santanu Datta: SharePoint: Removing HTTP Headers for Security Reasons

Introduction

Virtually any decent web security guide will recommend to obfuscate HTTP header revealing technical information’s over the technologies used to host and operate an internet-facing web site or application. In the case of SharePoint, each HTTP response is likely to include at least the following headers:

Server: Microsoft-IIS/7.5: Generated by Windows or IIS, it indicates the version of the HTTP engine or IIS SharePoint runs on
X-AspNet-Version: 2.0.50727. Generated by ASP.Net, it reports the ASP.Net version used on the IIS site
X-Powered-By: ASP.NET: The text says it all :)
MicrosoftSharePointTeamServices: 14.0.0.6109 . Supposedly reports the SharePoint Build Number. Refer to my article Retrieving the Current Build Version Number and to the one from Wictor Wilén: SharePoint Mythbusting: The response header contains the current SharePoint version
SPRequestGuid: 11ca6867-9228-455b-a8d9-ddd3e367de86. Implemented from SharePoint 2010 for diagnostics purpose to identify request in order to map them to entries in the ULS logs
X-SharePointHealthScore: 0. Indicates to the client the health status of the server on a scale from 0 to 10. The lower the better

SharePoint comes with many more headers, they are documented on MSDN: [MS-WSSHP]: HTTP Windows SharePoint Services Headers Protocol Specification.

Some headers are absolutely necessary for SharePoint to function properly. Therefore, make sure you intensively test before implementing changes in production. As an example, removing the header MicrosoftSharePointTeamServices will simply prevent SharePoint from indexing its own content properly.

In a nutshell, there are 3 ways to remove HTTP header in response:

By disabling it on Windows, IIS or anything running on op of this stack. However this will not address all headers
By filtering them using modules or filters at IIS-level on the SharePoint Server
By filtering them on a server, device or Appliance off the SharePoint server

Not all methods above are equal, as this post will explain.

Disabling HTTP Headers

A Word about the Server Header on Windows

On the Windows Platform (client or server), the web service infrastructure is divided into 2 core components like depicted in the schema below (source: MSDN): The kernel mode HTTP driver, present on every recent version of Windows and a server application like IIS, which comes as an optional component (a server role, a feature or even a third party software.

As consequence and dependin on the actual configuration of the system, the “Server” header in reponses will originate from the HTTP.SYS driver or from IIS (or even from another server application). This explains why you may witness at least two contain for this header:

Server: Microsoft-HTTPAPI/2.0: This one comes from the HTTP.SYS driver
Server: Microsoft-IIS/8.0: This one comes from IIS

Removing the Server Header in HTTP.SYS

Open Windows Registry Editor (REGEDIT)
Navigate to HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
Create a DWORD entry named DisableServerHeader and set its value to 1
Restart the HTTP service by executing the commands NET STOP HTTP then NET START HTTP
Then if IIS is installed, restart it as well by executing the command IISRESET

Removing the Server Header in IIS using URLScan Extension

Download and install Microsoft Urlscan v3.1 according to the CPU architecture of your server: x86 or x64
Use NOTEPAD to edit the file URLScan.ini located Under %WINDIR%\System32\Inetsrv\URLscan
Locate the line containing the element RemoveServerHeader, make sure it is set to RemoveServerHeader=1
Save the file
Restart IIS by executing the command IISRESET

Removing the X-AspNet-Version

For each Web Application, edit its Web.config file
Locate the element httpRuntime under system.web
Add or modify the attribute enableVersionHeader to set it to false
Save the file. It will automatically unload the Application Domain and apply the change

<configuration>

  <system.web>

    <httpRuntime enableVersionHeader="false" /> 

  </system.web>

</configuration>

Removing the X-AspNetMvc-Version

This header must be addressed in a programmatic way by adding line hereunder to the code.

In C#:

MvcHandler.DisableMvcResponseHeader = true;

In VB.NET:

MvcHandler.DisableMvcResponseHeader = True

Removing the X-Powered-By HTTP Header

This header is generated by IIS and is based is simply based on a configuration element. It is therefore easy to remove it or even to set an arbitrary value.

Start the IIS Manager
Expand the Sites element in the left pane
Select the site where the header must be modified
Under the IIS section, double-click on the icon HTTP Response Headers
Select X-Powered-By then click Remove in the right pane

Removing SharePoint’ Specific Headers

SharePoint does not come with a configurable way to remove its own headers.

Filtering HTTP Headers on SharePoint Server

The methods described in the sections hereunder will allow removing nearly any HTTP Header.

Using URL Rewrite IIS Module

Download and install Microsoft URL Rewrite Module 2.0 for IIS according to the CPU architecture of your server: x86or x64
Start the IIS Manager
Expand the Sites element in the left pane
Select the site where the header must be modified
Under the IIS section, double-click on the icon URLRewrite
Click on View Server Variables in the right pane
Click on Add then enter RESPONSE_SERVER in the free text box
In the new rule definition, set an empty value for the header to be filtered

Below the equivalent of a rule in XML format as stored in the Web.Config file of the site:

<rewrite>

   <outboundRules>

      <rule name="Remove X-Powered-By" >

         <match serverVariable="RESPONSE_X-Powered-By" pattern=".+" />

         <action type="Rewrite" value="" />

      </rule>

   </outboundRules>

</rewrite>

Dionach’s IIS Native Code Module

The following blog post by Dionach comprehensively covers this method: Easily Remove Unwanted HTTP Headers in IIS 7.0 to 8.5

HeliconTech’s IIS ISAPI_Rewrite

This tool is a port of the well-known Appache mod-rewrite module. It comes as a commercial as well as a free “light” version available from their web site:

ISAPI_Rewrite 3 – Apache .htaccess mod_rewrite compatible module for IIS

Filtering HTTP Headers off SharePoint Server

Using F5 BigIP Load Balancer

With BigIP, it’s a no-brainer with the command http::header with iRule, example:

when HTTP_RESPONSE {

   # loop through and remove all instances of the unwanted

   # headers from the server response

   # (Server, X-Powered-By in this example)

   foreach header {Server X-Powered-By} {

      log local0. "Removing $header: [HTTP::header value $header]"

      HTTP::header remove $header

   }

}

Using Forefront UAG 2010’s AppWrap

Using AppWrap, it’s a little more complex but in a nutshell, a rule similar the one hereunder can be used:

<APP_WRAP ver="3.0" id="WhlFiltAppWrap_HTTPS.xml"> 

   <MANIPULATION> 

      <HEADER_CHANGE> 

         <RESPONSE> 

            <APPLICATION> 

               <APPLICATION_TYPE>SharePoint</APPLICATION_TYPE> 

                  <URL> 

                     <URL_NAME>/*</URL_NAME> 

                     <DELETE> 

                        <HEADER> 

                           <NAME>MicrosoftSharePointTeamServices</NAME> 

                        </HEADER> 

                     </DELETE> 

                  </URL> 

            </RESPONSE> 

       </HEADER_CHANGE> 

    </MANIPULATION> 

</APP_WRAP>

Conclusions

While it’s always funny to play around with custom .Net HTTP module or even ISAPI filters, I would definitely not recommend this solution to remove HTTP headers since it may break SharePoint functionalities and place a certain load on SharePoint server(s). Not to mention additional hassle in case you have to troubleshoot something in the IIS/SharePoint pipeline. I also recommend reducing as much as possible customizations at SharePoint level to improve manageability and help keeping service costs low.

The same logic applies to ASP.Net or MVC configuration changes but with a lower importance.

Instead and if you’re minimally serious about SharePoint infrastructure security on the Internet, you will not expose it directly but place a security gateway or reverse-proxy in front. Those security devices or servers usually come with the capability to alter HTTP headers easily and with a near-zero footprint compared to a solution implemented on the SharePoint server.

This way, you keep your SharePoint fully functional while another device does the actual security job.

Do not mess around with custom HTTP Module, ISAPI or other configuration change unless you have no other way.

Finally, while it gives a feeling of security, it will only prevent robots, probes or scripting kiddies to identify the underlying OS or web server. Real hackers do use technically superior methods insensitive to this countermeasure.

Santanu Datta

Wednesday, December 2, 2015

SharePoint: Removing HTTP Headers for Security Reasons