Security Hardening your SharePoint Environment

This post is focussing on some SharePoint/IIS specific security hardening points for internet facing web sites.

I'm not going to cover the more infrastructure focussed security aspects you should also be looking at such as SSL, Kerberos, Firewalls, SQL encryption etc.

When exposing your SharePoint site to the internet or working with a project where security is a key concern you may need to look at security hardening your SharePoint implementation.

With this post I am aiming to create a combined guide for two key points that penetration testers will usually flag up regarding the IIS/SharePoint configuration.

1. Removing IIS Headers for SharePoint and ASP.Net
2. Using custom error pages to mask the underlying technology being used

Removing the page HTTP headers:

When removing or trimming the headers, the tool I used to check these headers was Fiddler but there are various tools you could use for this purpose.

You will be able to spot vital pieces of information within the headers tab, these are the first thing hackers will look for.

From the screenshot below, you can clearly see the IIS and SharePoint version, which can then be used to research security vulnerabilities in those particular versions.

1. Open IIS Manager.

2. At the server level and the site level you will find 'HTTP Response Headers'.

3. On the HTTP Response Headers page, select the header and click remove..

To remove the SharePoint version number, and the ASP.Net version number you need to modify the web.config file for the web application.

Remove SharePoint version number

    <httpProtocol>
      <customHeaders>
        <add name="X-Content-Type-Options" value="nosniff" />
        <add name="X-MS-InvokeApp" value="1; RequireReadOnly" />
<remove name="MicrosoftSharePointTeamServices"/>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>


Remove ASP.NET version

    <system.web>
      <httpRuntime maxRequestLength="2097151" executionTimeout="3600" enableVersionHeader="False" />
    </system.web>

After these changes you should no longer see the SharePoint version or .NET version.

When it comes to error pages, hackers can sometimes manipulate URLs and expose IIS error pages which give direct hints at the technology in use (IIS) and also more detailed information such as IIS or ASP.Net version numbers. These version numbers can be used to find security vulnerabilities.

I was able to access the below error pages by manipulating the URL.

To start with we can change the custom error pages in IIS.

When it comes to SharePoint error pages, we have two ways that error pages are managed within SharePoint.

Create your custom error page, which can be a simple html page to start with or something more customised for your needs.

Save your custom error pages to the below location on your SharePoint servers:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\1033

Set the SharePoint error pages on non publishing sites:

$webApp = Get-SPWebApplication https://testsite.com
$webApp.FileNotFoundPage = “CustomError_Page.html”
$webApp.Update()

$webApp = Get-SPWebApplication https://testsite.com
$webApp.UpdateMappedPage([Microsoft.SharePoint.Administration.SPWebApplication+SPCustomPage]::Error,"/_layouts/1033/CustomError_Page.html")
$webApp.Update()


A publishing site has its own attribute,

If you set the site level error page to a blank value "" then the web app level setting we just set will override this and the site will be consistent with the other non publishing sites.

$site = get-spsite 'https://testsite.com'
$site.FileNotFoundUrl = “”

I hope these tips help.

Thanks for reading,
Matt