Guideline to hardening your SharePoint 2013 against HPE WebInspect

I’ve written many articles on the topic of security with Microsoft SharePoint Server 2013 in which I shared my experience and lesson learnt during my time working with government agencies where my duties were to make sure their SharePoint 2013 farm as secure & stable as possible. Such a duty sounds challenging because SharePoint is a platform containing number of different components that you cannot just break down to implement something. Part of my role out there, I have to make sure if something is flagged, it must be remediated as soon as custom application gets approved to be deployed into production environment.

One of my customers are keen on HPE WebInspect. They choose it as the main web application vulnerability assessment tool for their SharePoint roll-out to approximately 20,000 staffs. Since the tool was used, I’ve been challenged in the report the tool generates every time a custom application needs to be scanned before the production roll-out. In this article, I just want to share some of the common findings which you may have to fix yourself or call to Microsoft Support for a confirmation of false positive flags. Before you start, I’d highly recommend you to read previous SharePoint security-related articles below:

This article is going to provide you guidance on recommendation and remediation of issues in a SharePoint 2013 environment that HPE WebInspect tool may report.

Disclaimer: The remediation may not be applicable to some scenarios and must be taken into consideration for SharePoint platform specifically. It basically means my recommendation is not for every case. It must be tested, and get approval by your security personnel. Moreover, my recommendation is just preventive action to clean up security flags which is found by WebInspect. To fully prevent, perhaps you need more custom function to authorize or validate each request. This would contribute to huge effort and is out of scope of my article.

If you have never heard HPE WebInspect, time for you to read some kind of marketing material here The name perhaps is changed to Fortify WebInspect. In SharePoint context, WebInspect crawls all links of your site collection URL input then try to send payloads to retrieve information whether sensitive or non. The vulnerability relies on the international trusted well-known source which is up-to-date.

Expression Language Injection

WebInspect may detect an Expression Language (EL) injection vulnerability. EL injection vulnerability are introduced when an application fails to sufficiently validate untrusted user data before assigning it to attribute values of certain Spring MVC JSP tags. The flagged link is Search query web service (spsearch.asmx) in SharePoint. Obviously SharePoint is a .NET based framework, which does not contain any objects related to Sprint MVP JSP particularly or Java platform generally.

During my investigation, the action was to try the URL in Internet Explorer. The error displayed as below:

I want to make sure even if SharePoint is not Java based platform, when WebInspect sends an HTTP GET method to the target URL, SharePoint should return nothing or a friendly message. Unfortunately in this case SharePoint does not. Instead, it threw out the error below saying A potentially dangerous Request.Path value was detected from the client (%). This error means that the server processes the URL and considers some characters to be illegal. That sounds like just another problem found. The workaround was to modify requestPathInvalidCharacters parameter to exclude all special characters when querying URL. Open web.config of the web application and replace by the snippet code below

This action may lead to security vulnerability that allows attacker to query to web server using exploitable parameter. You need a whitelist of special characters you allow. For more information, read this article Experiments in Wackiness: Allowing percents, angle-brackets, and other naughty things in the ASP.NET/IIS Request URL

Unprotected _vti_pvt directory 

The service.cnf file was found in the _vti_pvt directory on a system running Microsoft FrontPage Server Extension. This file contains meta-information about the web server. An attacker could submit a request for the vulnerable file cause the server to reveal sensitive system information. The attacker could use this information to launch further attacks against the affected host.

This file contains SharePoint version information and is required for FrontPage RPC support. It is also to allow legacy software to connect to SharePoint. This information in this file is sent in the header of all HTTP requests to the server so having access to this file does not warrant a Configuration Disclosure. I did write an article to clarify FrontPage Server Extensions in SharePoint 2013

Insecure SSL: Missing HTTP Strict Transport

HTTP Strict Transport Security (HSTS) policy enables web applications to enforce web browsers to restrict communication with the server over an encrypted SSL/TLS connection for a set period. Policy is declared via special Strict Transport Security response header. Encrypted connection protects sensitive user and session data from attackers eavesdropping on network connection.

The solution is to add a custom header in IIS to accept HSTS. Open web.config of the web application and add a new custom host header inside httpProtocol element.

Another solution is to install and configure HTTP Strict Transport Security IIS Module ( However, there is no official documentation from Microsoft confirming this module is safe. This module made no impact on my SharePoint per my experiment.

Dynamic Code Evaluation: Code Injection

JSON Hijacking is an advanced attack that is similar to Cross-Site Request Forgery, however unlike CSRF a malicious site is able to obtain information from the target site. This interception (“hijacking”) of confidential data occurs when a response to a HTTP GET request is returned in JSON format. JSON Hijacking is a technique that through overloading the Array or Object constructors in browser scripting languages with constructors whom intercepts the data. This allows the malicious site to monitor JSON messages and possible steal sensitive data.

Use X-Frame-Options header to avoid Hijacking as recommended by Microsoft. The solution is to add X-Frame-Option header to safely handle HTTP header response. Open web.config of the web application and add inside customHeaders element.

Unprotected BIN folder

WebInspect recognized directory enumeration vulnerability in BIN folder after it sent the request to the BIN folder in SharePoint. Risks associated with an attacker discovering a directory on your application server depend upon what type of directory is discovered, and what types of files are contained within it. The primary threat, other than accessing files containing sensitive information, is that an attacker can utilize the information discovered in that directory to perform other types of attacks.

BIN folder is used to store code files that can expand the functionality of SharePoint. Custom development code files that are compiled as .dll files are typically deployed to Bin folder or Global Assembly Cache (GAC). You need to restrict permission on BIN folder for only SharePoint service accounts. By default this folder is accessible anonymously.

Privacy Violation: BREACH

This one used to be my nightmare when wearing SharePoint architect and farm administrator. The Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) attack is a type of site-channel attack that allows attackers to steal sensitive information contained in HTTP responses transferred over an SSL/TLS-enabled channel. One of the recommendations found over the Internet is to disable HTTP Compression on both type of content: dynamic and static. At least we know doing so makes no impact on SharePoint from business functionality perspective, except bandwidth and performance. Open web.config file of the web application and add the following line

Disabling HTTP compression was not effective to changing the WebInspect’s result. In my case, I opened a support ticket to Microsoft to get their advice. Fortunately Microsoft confirmed the platform had no BREACH vulnerability which I was able to answer my customer.

Insecure Deployment: Unpatched ActiveX

WebInspect detected the use of an ActiveX object. This could indicate vulnerability is present if a vulnerable public version of the Microsoft Active Template was utilized. There are three vulnerabilities in the public versions of the Microsoft Active Template Library (ATL) included with Visual Studio.

Carefully test and apply Operating System security updates (

Insecure Application page

This is not actually what WebInspect is able to reach to but sometimes WebInspect may not be able to access to application page (e.g. /viewlsts.aspx) to scan the target site collection even anonymous access is enabled. It’s because t’s because the Limited-access user permission lockdown mode feature is activated. When this feature is enabled, permissions for users in the “limited access” permissions level (such as Anonymous Users) are reduced, preventing access to Application Pages.

Run the following PowerShell script to disable Limited-access user permission lockdown mode feature

To be continued…


Leave a Reply

© 2018 The Soldier of Fortune.