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.
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.
… do not misconfigure security-relevant settings!
… do not over-customize server-side code!
… do not trust 3rd party code!
Cross-Site Scripting (XSS)
- 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.
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):
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:
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
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:
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?
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 ...
XSS mitigation affects governance, logical architecture and configuration.
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.
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.
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
- Research work and talk
- MS Technet: SharePoint 2013
- Allow or prevent Contributors ability to edit scriptable Web Parts
- Are you Safe Against Script?
- Web Sensitive Files and SharePoint 2010
- Safe Controls list
- Security for SharePoint Solutions
- Configure and deploy Web Parts
What a amazing post. One of a kind! Thank you.
What about those SharePoiny columns with rich text enabled? Is it possible a member to inject JS in such a field?