I am frequently approached by Web developers and security managers who are frustrated by the complexities of securing RESTful web services. They are right. The OWASP REST security Cheat Sheet recommends 19 best practices for securing RESTful sites – an overwhelming amount of work. In this post I’ll focus on one of the key challenges of REST security: its implementation on SharePoint.
The Problem (or: how I hacked a RESTful financial site in less than 10 minutes)
To demonstrate the problem I examined a public RESTful website built with SharePoint. The site belongs to a large financial institution. It is protected by several WAF units, IPS, IDS and DDoS mitigation systems, and yet within 10 minutes I was able to access restricted data on that site:
The site implemented a request intended to return a mortgage calculation when changing the position of a slider as follows:
A clever attacker would attempt to use such a request to grab as much data as possible. So to follow an attacker’s line of thought I tried running the following command:
Look at the response which I got – it includes some useful and relevant information in the GUID:
At this point the attacker has gained access to SharePoint lists and has the ability to execute a direct call to the REST API, and request any SharePoint list in order to get hold of sensitive customer data; e.g.: http://server/site/_api/web/lists(‘<guid>’)/items$top=10
Why is a REST Site So Vulnerable?
So – how was I able to get through several WAFs, IPS and IDS systems, and access restricted data?
In our case the developers did not block external access to all restricted Web assets as required, and since my requests were legitimate the security systems could not identify any problem and passed them through. Unfortunately, 2 flaws coincided:
1. The command was not implemented securely
2. The WAF managers missed a REST/SharePoint vulnerability in their security policy.
The RESTful API very often uses GET, POST and DELETE, however, not every user and every functional context requires these methods. Leaving these methods enabled results in the vulnerability we have experienced.
So How Do We Protect a RESTful site?
The OWASP guides developers to enable only the required methods for each context. Developers should plan user permissions carefully and disable unnecessary calls that potentially risk the system.
From the security manager’s side – improving the WAF security policy and defining the syntax I used as illegitimate would have prevented the vulnerability we have experienced.
Here is a conventional todo list for protecting a RESTful/SharePoint site:
- Review and enforce the OWASP REST cheat sheet best-practices
- Harden Sharepoint, review and update configurations:
- Ensure that services run in low privileges, or define new users
- Eliminate exposure to error messages
- Separate read-only uses for User Interface access and Read/Write for management interface –at the architecture level
- Map all methods, make sure that only the required ones are exposed
- Harden the scheme and data structure that the service should enable
However – both approaches are unrealistic. Going over each API call is time consuming, error prone, and requires IT people, infrastructure and developers to collaborate.Therefore, my preferred approach is using context-aware protection.
Context-aware protection understands the context of an incoming request and can therefore make a smart decision on whether the request is valid within its context. So, for example, a GET request will be valid when attempting to retrieve a list of countries for a menu, but will be blocked when attempting to retrieve a private list of users. No other API calls are allowed.
There is no single foolproof approach to protecting RESTful sites. My view is that best practices for secure development should be followed, however, we cannot rely on them alone to protect our website. What is your experience and which tactics have been successful for you?