Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem

SharePoint: Removing HTTP Headers for Security Reasons

Leave a comment

SharePoint 2007 SharePoint 2010 SharePoint 2013</

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 IIS, it indicates the version of IIS SharePoint runs on
  • X-AspNet-Version: 2.0.50727. Generated by ASP.Net, it reports the ASP.Net version using 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 actually comes with many more headers, they are documented on MSDN: [MS-WSSHP]: HTTP Windows SharePoint Services Headers Protocol Specification.

Removing ASP.Net and MVC Headers

This article from 4 Guys from Rolla covers the topics comprehensively.

Removing SharePoint Specific Headers

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

My Recommendation

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 attempt, as much as possible, to reduce customization at SharePoint level to improve manageability and lower service costs.

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.

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

Removing Headers using F5 BigIP

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
   }
}

Removing Headers using Forefront UAG 2010

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>

<REQUEST>

<APPLICATION>

<APPLICATION_TYPE>SharePoint14AAM</APPLICATION_TYPE>

<URL>

<URL_NAME/.*</URL_NAME>

<DELETE>

<HEADER>

<NAME>X-Powered-By</NAME>

</HEADER>

</DELETE>

</URL>

</REQUEST>

</HEADER_CHANGE>

</MANIPULATION>

</APP_WRAP>

Conclusions

  • Do not mess around with custom HTTP Module, ISAPI or other configuration change unless you have no other way.
  • Like best practices usually recommend it, place you internet-facing SharePoint behind a security device such as ForeFront UAG and use that security device to do the response obfuscation work
  • Note1: Removing headers is only one step in the direction of securing Internet-facing SharePoint
  • Note2: While it gives a feeling of security, it will only prevent robots, probes or scripting kiddies to identify the underlying technologies. Real hackers use superior method insensitive to this countermeasure
  • Note3: But at least, the security audit will not blame you for exposing those headers on the Internet 🙂

More Information’s

Marc

Advertisements

Author: Marc Lognoul

Relentless cloud professional. Restless rider. Happy husband. Proud father. Opinions are my own.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s