SharePoint is a very popular browser-based collaboration and content management platform. Due to its high complexity, proprietary technology and confusing terminology it is often perceived as a black-box that IT and security professionals do not feel very comfortable with.

These days, web security topics are well understood by many security professionals, penetration testers and vendors. But what about Microsoft and one of their flagship-products SharePoint? Is it secure? What do I need to do to make it secure?

I would like to take a couple of minutes to explain how Microsoft SharePoint protects your assets from one of the OWASP top 10 vulnerabilities, Cross-Site Scripting (XSS). Other topics like Cross-Site Request Forgery (CSRF), SQL Injection (SQLi), Open Redirects or malicious HTML Fields (iFrames) will be covered in later posts.

TL;DR

As is the case with many other modern Microsoft products, SharePoint comes with secure defaults. It’s the configuration changes implemented to satisfy business requirements or customization done by 3rd party solution providers that introduce new vulnerabilities undermining the built-in security concept of SharePoint.

SharePoint uses weirdly named settings which heavily depend on each other rendering misconfiguration likely and thus leaving the door wide open for unauthorized access by adversaries with SharePoint skills. Most of the SharePoint environments tested by Compass Security have been misconfigured in a way that it allowed unauthorized access to critical documents or could be used by disgruntled employees to host malicious web content (XSS, Flash exploits, etc.) in the Intranet.

Therefore,
… do not misconfigure security-relevant settings!
… do not over-customize server-side code!
… do not trust 3rd party code!

Cross-Site Scripting (XSS)

An XSS vulnerability allows adversaries to store arbitrary JavaScript code on a website. The malicious code gets automatically downloaded and executed in the browser of any user visiting the website. If the user is authenticated, the attacker can access any information which the victim is authorized for. As long as the victim stays on the vulnerable website and does not close the tab / browser window, the attacker can remotely control the browser and trigger any action on that website in the name of the victim. E.g.

  • Execute fraudulent transactions
  • Upload malicious content
  • Damage the site owner’s reputation
  • Attack other websites using the authenticated browser
  • Redirect users to faked login pages (phishing)
  • Redirect users to a website that exploits browser vulnerabilities (drive-by)

On a SharePoint collaboration and file sharing platform this means that a disgruntled employee could gain access to sensitive documents shared among the HR team or an external partner could try to get hands on sensitive internal pricing information of the sales team or highly confidential patents of the research department.

The good news: SharePoint in its default configuration is not vulnerable to XSS attacks; the bad news: SharePoint provides the option to deploy JavaScript code as a feature, ergo XSS by design. However, all SharePoint features allowing users to insert JavaScript code, require a specific permission called Add & Customize Pages. The problem is, an interdependent set of opaquely named settings need to be correct in order for this XSS-prevention to be effective. One needs to fully understand the relationship between these settings and know the dangerous features to avoid that configuration changes (e.g. requested by VIP users) undermine the SharePoint security concept.

Web Parts

Let’s start with the Web Parts. They are used to render content on so-called Web Part Pages. These are the main building blocks on SharePoint to aggregate and visualize content on SharePoint. SharePoint is shipped with several Web Parts that allow privileged users to embed JavaScript by design. They are known as Scriptable Web Parts. The most famous ones are the (obvious) Script Editor or the (not-so-obvious) Content Editor Web Part. Let me show you how they can be used to perform XSS attacks:

The following sequence allows users with Add & Customize Pages permission to add arbitrary JavaScript code.

First, switch a page (Web Part Page) to edit mode and choose to Embed Code:

Second, insert code (this adds a Script Editor Web Part on the page):

Save the page (otherwise it will not be loaded by other users):

The embedded JavaScript (XSS) will be executed in every visitor’s browser:

Remember, this is not a vulnerability. It is a feature that can only be used by users with the Add & Customize Pages permissions.

Let’s edit another page and do the same with a less obvious Scriptable Web Part:

Add a Content Editor Web Part to the page (designed to allow users to embed rich text content to pages):

Let’s make sure the text division is selected and then Edit Source:

Add some JavaScript to your HTML Source and save the page:

Note: If you try to do the same (Edit Source) on other parts on a SharePoint page the JavaScript gets automatically removed / sanitized by SharePoint.

But not in the context of a Content Editor Web Part:

If you try to do the same with a user that has the right to edit but not Add & Customize Pages, you will be confronted with the following error:

So, how does SharePoint know which Web Part is dangerous and which are not?

It is the web.config of the given SharePoint Web Application that declares a Web Part as safe against scripting. E.g. Scriptable Web Parts must not be flagged as SafeAgainstScript in the <SafeControls> section as shown in this example:

Web Parts declared as SafeAgainstScript require the user to have the Add & Customize Pages permission. By default the roles Designer and Owner have this permission. Since SharePoint 2010 the role Member (permission level Contribute), and therefore the majority of the users, do not have this permission, if the following Web Part Security Setting is set correctly:

I had to create a matrix for myself to understand all the pre-conditions for XSS attacks using Web Parts:

Web Sensitive Files

Another way to embed JavaScript or other malicious content in a SharePoint Site is the upload of malicious files (SharePoint knows them as Web Sensitive Files) in a Document Library. As an example, users with Add & Customize Pages permissions are allowed to edit Web Part Pages offline and upload them as ASP.NET pages (.aspx) with some limitations with regards to server-side controls, but JavaScript is allowed to be included:

Upload in Document Library:

Upload successful:

When clicked, SharePoint renders the ASP.NET page (.aspx file) and the JavaScript gets executed in the browser:

This is not a big surprise, since Owners are anyway capable of using Scriptable Web Parts. But what happens if a Member tries to upload potentially dangerous files?

SharePoint blocks ASP.NET pages (.aspx) and other files from being uploaded by Members, due to the missing Add & Customize Pages permission:

Wait a minute, normal HTML websites (.html) are not considered as potentially harmful, even though they could contain JavaScript as well?

Yes, because they are not on the SharePoint internal list of potentially malicious file types. Microsoft allows you to tightly control this list of so called Web Sensitive Files using Powershell. The list WebFileExtensions defines which file types are blocked from being uploaded by users without Add & Customized Pages permission (e.g. Members):

$sps.WebFileExtensions
ascx
asmx
aspx
jar
master
swf
xap
xsf
xsn

But still, why is HTML not on this list? This is where the Browser File Handling comes into play.

Browser File Handling

What happens if a user clicks on a HTML file?

Depending on the Browser File Handling setting some file types are not getting rendered which prevents embedded JavaScript from being executed in the browser, but why?

SharePoint adds the content-disposition header to the HTTP Response to ensure that potentially malicious files, uploaded by a Member, do not get rendered in the browser and therefore cannot be used to harm other users:

SharePoint calls the setting that controls this behavior Browser File Handling:

In many cases, SharePoint administrators are forced by the business to change this behavior which renders the default XSS prevention ineffective, because .html is not on the default list of Web Sensitive Files. If you change the Browser File Handling to permissive, you should add HTML and other potentially dangerous files to the list in order to prevent XSS. If not, you must understand that changing the Browser File Handling to Permissive, allows all your Members to execute XSS attacks in your SharePoint environment using simple HTML files.

Note: SharePoint ignores the setting Browser File Handling for all file types defined in the list AllowedInlineDownloadedMimeTypes. These files always get rendered, instead of being downloaded by the Browser:

$sps.AllowedInlineDownloadedMimeTypes
application/directx
application/envoy
application/fractals
...
application/x-shockwave-flash
...
image/bmp
image/cis-cod
image/gif
image/ief
image/jpeg
image/pjpeg
image/png
image/tiff
...
text/plain
text/richtext
...
video/mp4
video/mpeg
video/ogg
video/quicktime
...

Mitigation

XSS mitigation affects governance, logical architecture and configuration.

Governance

Since XSS in SharePoint is not a vulnerability, but depends on the permission a user has, every SharePoint environment sooner or later will have privileged users that are capable of executing XSS attacks. Usually these are the Owners of a team or project Site. This means you have two options, either you know all the Owners in your environment and trust them or you globally remove the privilege “Add & Customize Pages” from your Owner’s permission level. The latter will have significant impact on the usability. In fact the Owners will be very limited in the abilities to design the look and feel of their Site.

If you go with the first option and accept the risk of Owners being capable to inject JavaScript into the Site they “own”, you should minimize the risk by tightly controlling who can become a Site Owner within your environment. This can be a challenge due to the delegated, decentralized user management in SharePoint. Usually, companies find it hard to monitor who has which privilege on which Site. An alternative would be to remove the user management privilege from all users and strictly control Site access through AD Security Group Membership. Again, this would significantly limit the user experience (e.g. Sharing).

Logical Architecture

On a larger scale, the impact of an XSS attack can be contained by choosing the logical architecture wisely.

Due to the same origin policy, an XSS attack is always limited to the current site’s domain. By using dedicated domains for differently classified content, such as confidential documents or personal data that falls under privacy laws, e.g. sites of the Human Resources department (hr-sps.corp.ch), can be protected from XSS attacks on less secure sites in a different domains (research-sps.corp.ch, ext-sps.corp.ch, …). You can segregate SharePoint Sites in different domains on a Web Application level as well as on Site Collection (host-named) level.

Configuration

To make sure the threat of XSS attacks is limited to Owners of a Site one should carefully balance the following settings:

  • Central Administration > Web Application > Web Part Security Setting > Prevent contributors from adding or editing scriptable Web Parts
  • IIS Web Application directory > web.config > section SafeControls > attribute SafeAgainstScript=false
  • Powershell > WebFileExtensions
  • Central Administration > Web Application > General Settings > Browser File Handling > Strict
  • Powershell > AllowedInlineDownloadedMimeTypes

References