Approach to preventing PUT method in SharePoint

I’m not going to do a series of SharePoint security even I have been spending days doing security and SharePoint hardening for number of different public sector organizations. If you wish to collect my articles related to SharePoint security, see the list below.

One of the common examinations with almost vulnerability assessment (VA) tools is that they try to exploit the target website with popular HTTP methods including POST, PUT, MKCOL etc. What would be successful mostly is the creation of a file/page in SharePoint website. The result comes out with the recommendation of removing or denying PUT method.

Common Solution

What you would propose to your customer is to deny HTTP PUT method using IIS Request Filtering. The code snippet looks like as follows:

It looks like a quick solution you can do just a few minutes. However, if you deny PUT method you are to prevent your end-users from using Microsoft client integration especially Windows Explorer View for copying. Because the configuration needs to be applied at web application level then in the production environment it will impact on another site collection underneath that web application. It’s hard to get your customer accepting the fact that all end users using SharePoint give up Microsoft client integration feature.

You may approach Microsoft to have their confirmation as to why PUT is required to fully work with SharePoint client integration. The only team that can confirm is Microsoft Advisory team which requires you to be its premium partner.

Proper Solution

The common solution is workable to the case that there is only one site collection in a dedicated web application. In a large SharePoint farm there should not be one web application hosting one site collection because SharePoint only supports up to 20 web applications.

One of the proper solutions I would recommend is to use HttpHandler handling HTTP Verb and Path in a specific URL (site collection). In the custom HttpHandler you would have to define a class (i.e. DeniedRequestHandler) which gets inherited from IHttpHandler then deploy to GAC. In the web application configuration just add the following code snippet

Every PUT request to the specified site collection will handled by DeniedRequestHandler first. If it passes the request will reach to the target object.

Conclusion

There is not a right solution in this case. It depends on the acceptability level that your customer may have. My solution is just to mitigate the impact globally on a web application you disable HTTP method.

[Updated 18/04/2016]

Jame (https://twitter.com/jimmywim)-  a senior SharePoint expert had a quick conversation with me on Twitter as to why PUT used in any REST is blocked. To his question, my article does not recommend anyone to block PUT. It is still useful for REST request especially SharePoint Online. The article also does not indicate that PUT is vulnerable. In some cases if you deal with automatic vulnerability assessment tool, you need to justify your customer and they may require you to contact Microsoft. The problem is that Microsoft will not secure you by saying PUT has nothing to do with the hacker, and PUT should be kept. Microsoft won’t actually! You as a professional vendor need to sort the problem out and clear out what the VA tool has found.

One comment

Leave a Reply