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.
As SharePoint is a web-based platform it is supposed to have a trusted SSL certificate imported for better security. In a highly secure environment SSL certificate is part of security policy and is always required. In this article I’m going to share some cases you may have to deal with SSL certificate and SSL protocol.
UrlScan is a security tool that restricts the types of HTTP requests that IIS will process. This tool has number of different features which help you block specific HTTP request. Some of the outstanding features that UrlScan can help is the prevention of SQL Injection, XSS, HTTP Population attack. This sounds like a cheap weapon compared with any other security tools in the market. Ideally in any IIS web server UrlScan is supposed to be installed. In many organizations, UrlScan is part of the entirely hardening guideline for IIS. Now the question of UrlScan for SharePoint comes out. Is UrlScan still helpful to your SharePoint site? Would SharePoint be an exception? In this article, I’m going to share just a little of my experience when working with UrlScan in SharePoint environment.
Working and troubleshooting in a highly secure and hardened environment has never been easy. Recently my end users have reported an issue related to editing Microsoft Office documents in SharePoint 2013 environment. When they open a document from SharePoint document library, such as Microsoft Word document, there is a window pop-up asking the message “How would you like to open this file?” with two options: Read Only and Edit. Whether they select an option, Microsoft Word client application always set opening document read-only mode. If they click Enable Editing then make changes, Microsoft Word client application always asks them to save to their computer locally while they wish to directly save to SharePoint library.
The environment is a bit of special with two domain controllers. One is used to issue SharePoint service account while another is responsible for end user accounts. The environment has been implemented and hardened by the corporate security policies (e.g. Windows Server, IIS hardening guideline).
Request Filtering related article: IIS Request Filtering Whitelist and SharePoint 2013
After a few investigations, I have realized that if I allow OPTIONS, PROPFIND and HEAD methods through Request Filtering (HTTP Verb), I will be able to edit then save back to SharePoint document library directly. The existing corporate security policy only allows GET and POST methods. OPTIONS, PROPFIND and HEAD methods are involved to make WebDAV functional.
When you open Microsoft Office document from SharePoint (or any other file server), Internet Explorer (IE) ends GET request to download the file to the Temporary Internet Files on the client machine. IE invokes Office to open the document. Office then starts trying to determine if the file can be authored or not so it can open the file for editing or read-only. Office will issue OPTIONS call on the parent folder of the Office document to determine server capability. In case OPTIONS call can’t return expected headers or valid response, Office again tries to determine if it can author against this server or not by using more WebDAV calls: HEAD, OPTIONS and PROPFIND. If all calls fail, Office will open the document read-only. When you want to edit the document, Office doesn’t trust your document so it asks you to save somewhere in your computer first.
The following references can help if you are required to provide justification to your security team in order to allow special methods for WebDAV call.
If you have never performed vulnerability assessment using any tools, you are going to be surprised what the FrontPage Server Extensions means to SharePoint at least from the tittle and why it’s part of the assessment vector. If you see it one day in an assessment report when you are responsible for SharePoint security, you wouldn’t manage to easily remediate the issue or justify your security team. You could call Microsoft for a question but it’s not that just easy to do so almost time. What I’m going to share in this this article might show you the light at the end of the tunnel if you are stuck in whether fixing FrontPage Server Extension (FPSE) related vulnerability or justifying your security team.
Disclaimer: this article doesn’t provide you actual fix for the FPSE related issue or an official justification. The best way anyway is to call Microsoft support if you can’t convince your security team.
If you don’t know Microsoft FrontPage and Microsoft FrontPage Server Extensions, read the following articles:
What is detected?
When SharePoint 2013 is installed by default, there are two folders in which each name gives the assessment tool the sign of the FrontPage structure: _vti_bin and _vti_pvt. The _vti_bin folder contains several folders and built-in SharePoint web services. For example, you can see many web services for administrative tasks in the _vti_adm folder. The _vti_pvt contains files that show you current SharePoint version and its build when browsed. With that sign, the tool likely thinks that SharePoint 2013 still uses legacy FrontPage that is notoriously vulnerable historically. There are numerous vulnerability reports related to FrontPage you can quickly find from Google. There are the following URLs virtually detected after you run the assessment tool:
- contoso.com/_vti_bin/_vti_adm/(*) (the list of many URLs starting with this prefix)
- contoso.com/_vti_bin/_vti_aut/(*) (the list of many URLs starting with this prefix)
However, if you browse http://contoso.com/_vti_inf.html, you will see the blank page but its HTML source code contains some FrontPage configuration information. You even couldn’t find this file in SharePoint directory source.
What is reported?
Basically the assessment tool performs a GET method to crawled URLs and waits for response. If it receives something it thinks critical or sign of vulnerability, it will definitively repot. There are potential reasons as to why the tool reports about FPSE
- By the structure detected, your system is using FPSE that is said to be insecure almost time so far
- Disclosure of SharePoint version (_vti_pvt/service.snf)
- Disclosure of FrontPage Configuration Information (_vti_inf.html)
If you use HP WebInspect, the report will look like as follows:
The service.cnf file was found in the _vti_pvt directory on a system running Microsoft FrontPage Server Extensions. This file contains meta-information about the web server. An attacker could submit a request for the vulnerable file and cause the server to reveal sensitive system information. The attacker could use this information to launch further attacks against the affected host. Recommendations include removing this file from the system if it is not needed, or tightening the default permission settings.
If the tool uses directory enumeration scan, it may indicate that FrontPage allows remote users to upload and modify web site content. Historically, attackers seek out FrontPage sites since FrontPage is often misconfigured to not require authentication.
Another tool (IBM AppScan) even recommends you to upgrade the latest FrontPage version available. Anyway almost tools state that your system is potentially vulnerable with the existing FPES. The disclosure of configuration information needs to be restricted to authorized people.
What to do then?
Ironically there is no official statement from Microsoft saying that FPES is the last version or significantly improved from the security perspective. You could explain that SharePoint requires FrontPage Remote Procedure Call (RPC) and to allow legacy software to connect. FrontPage RPC is implemented by both FrontPage Server Extensions and by Windows SharePoint Services that is foundation of the SharePoint platform. This reference (FrontPage Server Extensions RPC Protocol) provides you a list of methods that requires FPSE RPC protocol (e.g. check-in document). Although it’s written for SharePoint 2010, it’s still true for SharePoint 2013.
Paul Stork – an internationally renowned SharePoint expert commented in the MSDN thread that you could use as an explanation:
That’s because SharePoint and SharePoint Designer are built on the foundation of the original FrontPage Server Extension. Note however that the version number is 14, which is in keeping with SharePoint 2010. They just didn’t change the internal naming as they enhanced the product.
If your SharePoint is anonymously accessible, you need to consider implementing authorization rule to restrict access to web services under _vti_bin, or at least prevent attacker from accessing to gain SharePoint version or FrontPage configuration information (_vti_inf.html). I’m not sure how the attacker utilizes the configuration information to exploit your SharePoint but it’s much better if you restrict access to all of them. See the sample code snippet to restrict _vti_inf.html
<deny users= "?" />
<allow users = "*" />
The asterisk mark (*) represents authenticated user and the question mark (?) represents anonymous user. This post (Restricting access to SharePoint 2013 web services) does give you more details.
Since FPES is still a nightmare, the best way I’d highly recommend you is to call Microsoft in case you can’t justify the harmlessness of FPES in SharePoint 2013 reported by vulnerability assessment tool. Even when you call, it’s still pretty hard for Microsoft to fully protect you. They may say that information found is sent in the header of all HTTP requests to the server so having access to this file does not warrant a Configuration Disclosure. As a result, there would be an everlasting debate between you (or Microsoft) with your security team. C’est la vie!
Additional helpful references:
If you have ever developed a facing-public website on top of Microsoft SharePoint platform for large organization, there is probably a penetration test procedure performed and you will be virtually asked to fix web application vulnerabilities found by the security team if any. One of the things you may deal with after receiving the assessment report is the exposure of built-in SharePoint web services. What the security team will likely ask you is why those web services are anonymously accessible and how to control access to them. This article is going to give you a few things in terms of securing SharePoint 2013 web services you should pay attention to.
SharePoint 2013 provides number of different powerful web services that unblock bunch of limitations in the previous SharePoint version developers have come across. Almost web services are located C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\isapi
When you enable anonymous access mode for the facing-public website, many web services are anonymously listed via the URL: http://consoto.com/_vti_bin/spsdisco.aspx . The vulnerability assessment tool surely detects those web services by crawling and iterating through the crawled list of URLs. The tool then comes up that the exposure is a threat that potentially allows attacker to utilize any of those web services to gain SharePoint data. Depending on the tool and how the security team sees, the rate of risk may vary. Finally anyway, the recommendation from the tool is to restrict access to web services to only authorized users. Now what you think is if those web services are restricted, your facing-public web site may not function correctly. The restriction may lead to unexpected error one day for even authorized users when working on a list that requires SharePoint 2013 REST. Not only you, I myself sometimes have that feeling.
Fortunately, IIS offers authorization rule that you can achieve securing the SharePoint 2013 web services. Authorization rule allows you to grant access to user or group to sites or folders under your web application.
To fully restrict access to SharePoint 2013 web services, there are two web.config files you must apply authorization rule:
- Web.config in ISAPI folder where all web services are located
- Web.config file of the facing-public web application
Open web.config file in ISAPI folder and add the following code:
<Allow users= "*" />
<Deny users= "?" />
The asterisk mark (*) represents authenticated user and the question mark (?) represents anonymous user. The above code snippet indicates that all authenticated users can access web services under _vti_bin directory. Anonymous users are denied. You can specify a domain account or group as well.
If your facing-public web application has site collection or sub-site, you must then add authorization rule into web.config file of the web application. The code snippet in this case looks like:
<deny users= "?" />
<allow users = "*" />
If you are lazy and don’t want to add many paths, you may be interested in implementing a solution in SharePoint that enumerates all site collections and sub-sites then adds multiple entries to the web.config using SPWebConfigModification class
[Important] You will have to deal with the call of REST API when anonymous users perform Search in your facing-public website. Although they see result, the Windows login constantly prompts. To solve this problem, see the following code snippet:
<allow users= "?" />
<deny users= "?" />
You need to test your facing-public website after implementing the authorization rule. Make sure web services work well with basic function (CRUD on SharePoint list is an example).
In IT security, whitelist and blacklist is always an everlasting debate. It’s like the causality “which came first, the chicken or the egg?” Folks say that whitelist is more controllable than blacklist. When you do whitelist, you allow things and believe those things to be safe to you. Folks, on the other hand, protect by pointing out that blacklist is more effective. With blacklist, you are to identify what need to be avoided to protect your system.
The client I’m currently working for picks whitelist and has asked me to make a list of allowed file extensions through IIS Request Filtering in SharePoint 2013 environment. This article is going to clarify a few things I have experienced during the implementation of whitelist for file extension in SharePoint.
IIS Request Filtering is a built-in feature that contains several options to secure web application against common web attack techniques, such as SQL Injection, XSS. File extension filtering is one of the options allowing you to control what file extensions you allow or deny when IIS receives request. You can find <fileExtension> element in global IIS configuration applicationHost.config (C:WindowsSystem32inetsrvconfig). The blacklist is set by default with <allowUnlisted = “true”>. This basically means all file extensions listed in the element are not allowed. If you want to make a whitelist, you need to change to false then provide the list of file extensions to be allowed. Let’s start an example in SharePoint scenario.
When you open a SharePoint landing page, your browser sends to IIS a request to retrieve some SharePoint built-in files. These files include normal CSS file (corev15.css) to render the page. Let’s say if CSS file extension is not in the whitelist in IIS Request Filtering. The landing page can’t fully render. This means all requests to retrieve SharePoint CSS file are denied.
Another example is trying to download an uploaded file in SharePoint library. If its extension is not in the whitelist, you will receive an HTTP 404.7 error because IIS blocks the request to the file.
In SharePoint, we have a feature named Block File Type that can be configured in Central Administration. It is quite different from IIS Request Filtering but people sometimes are a bit confused. This feature provides you the ability to restrict file extension from whether being uploaded or download in SharePoint. If you try to upload a file whose extension is blocked, you will encounter SharePoint error, even you use attachment method. See the result below after I tried attaching SharePoint_Setup.exe to a list item.
Similarly, you can’t download a file that is blocked.
When uploading to SharePoint, no matter what file extensions being added to the whitelist in IIS, SharePoint only checks file extension in the Block File Type list then allow or block accordingly. The similarity between IIS Request Filtering and Block File Type is the GET method. If an extension is both added to IIS whitelist and SharePoint Block File Type, the final result will come out from SharePoint. IIS checks the whitelist prior to SharePoint. The flow below would explain a little more.
Gotchas and Consideration
The blacklist is set out by default. It, however, doesn’t matter if your SharePoint web application doesn’t inherit request filtering settings. Once the request filtering is applied to specific web application (Configure Editor, select system.webServer/security/requestFiltering section then click Revert to Parent), there are some gotchas and considerations for whitelist.
- Add *.ascx as it is to call SharePoint controls. Blocking *.ascx causes unloading query on user in People Picker.
You may ask as to why *.ascx is in the blacklist by default but your SharePoint is still working. The reason is the default global setting of request filtering is not applied to your web application until you configure to inherit.
- If you use whitelist, make sure you fully test as many files as possible that make your SharePoint work.
- If you have theme packaged by Design Manager, it may include *.themedcss and *.themedpng.
- Back up applicationHost.config and web.config file every time before making changes on them. If you don’t, reverting back to original state wouldn’t be possible even you run Farm Configuration Wizard.
- If your SharePoint farm has multiple web front-end machines, you must apply the setting on every machine.
You might need to read determine your web front-end server article.
- If you happen to see HTTP 404 (namely 404.7) error when opening root site (http://abc.com/) or site contain explicit URL after making a whitelist, chances are IIS blocks your request. Check if <add fileExtension = “.” allowed =”true”> in the list.
- Make sure there is no duplicate made in the IIS whitelist and SharePoint Block File Type.
Below is the list that would make SharePoint work. Note that there are archiving types (RAR, ZIP) or video types in accordance with the requirement. They may not be applicable to your environment.
- aspx (Web page extension)
- asp (Web page extension)
- html (Web page extension)
- htm (Web page extension)
- . (To handle root site or explicit URL (e.g. https://contoso.com/sites/portal)
- axd (ScriptResources.axd is to reduce the size of script files)
- ascx (SharePoint Control file)
- css (CSS extension)
- svc ( SharePoint WCF Web Service extension)
- dll (DLL extension)
- asmx (SharePoint Web Service extension)
- webpart (SharePoint Web Part extension)
- cab (SharePoint package cabinet extension)
- xml (XML extension)
- csv (CSV file extension)
- txt (Text file extension)
- gif (Photo extension)
- png (Photo extension)
- jpg (Photo extension)
- jpeg (Photo extension)
- bmp (Photo extension)
- spcolor (SharePoint color palette file extension)
- spfont (SharePoint font file extension)
- preview (Master page preview file extension)
- xsd (Used to validate XML)
- master (SharePoint Master Page extension)
- eot (SharePoint Font File Type extension)
- woff (SharePoint Font File Type extension)
- odttf (SharePoint Font File Type extension)
- svg (XML-based vector image extension)
- htc (HTML file with some XML elements defined inside)
- xap (Silverlight extension)
- sql (SQL Server Transaction-Script extension)
- xsn (InfoPath)
- doc (MS Office Word extension)
- docx (MS Office Word extension)
- xlsx (MS Office Excel extension)
- xls (MS Office Excel extension)
- vsd (MS Office Visio extension)
- vdx (MS Office Visio extension)
- ppt (MS Office PowerPoint extension)
- pptx (MS Office PowerPoint extension)
- mpp (Microsoft Office Project extension)
- mp4 (Video extension)
- wmv (Video extension)
- flv (Video extension)
- avi (Video extension)
- themedcss (CSS extension in Design Manager package)
- themedpng (Photo extension in Design Manager package)
If you know any missing file extensions, please feel free to comment or contact me at email@example.com. Your contribution would be very much appreciated.
The second article of the series covered infrastructure stuffs, basic network security such as building a reliable perimeter that minimizes threats to your SharePoint farm. It also provided you fundamental steps in Windows Server hardening that can eliminate potential vulnerabilities. (more…)
The previous article brings out a picture of security that consists of five areas: infrastructure, application, database, content and compliance that you should be aware of when planning for information security in your SharePoint intranet collaboration. This article begins with the first area: network infrastructure & system (referred to network infrastructure or IT infrastructure as I think the term “infrastructure” is very general). This article won’t cover “security in depth” of network infrastructure, such as TCP/IP security, network package or OSI protection. If you are working in a large company, there should be a network & security team coordinating with you in protecting SharePoint. (more…)