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:
<Configuration> <system.webServer> <security> <authorization> <Allow users= "*" /> <Deny users= "?" /> </authorization> </security> </system.webServer> </configuration>
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:
<location path="sub-site/_vti_bin"> <system.web> <authorization> <deny users= "?" /> <allow users = ”*” /> </authorization> </system.web> </location>
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:
<location path="_vti_bin/client.svc"> <system.web> <authorization> <allow users="?" /> </authorization> </system.web> </location> <location path="_vti_bin"> <system.web> <authorization> <deny users="?" /> </authorization> </system.web> </location>
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).