The Challenges in Securing REST APIs

Print Friendly, PDF & Email

This is the second in a three-part series on REST APIs. You can read the entire series here. 

In our previous post we alluded to new challenges in securing RESTful APIs. As promised, let us dive into some of the details.

Let us begin with some typical aspects of REST that have bearings on API security.

 Use of HTTP/S: Instead of using complex technology like CORBA, web services, RPC, etc., it uses simple HTTP for communication between machines. Some APIs support HTTPS only. Thus, RESTful services are subject to all the application layer security vulnerabilities that traditional web applications have had to deal with over the years (e.g. OWASP Top 10, etc).

Use of HTTP Methods for CRUD: REST-based services map CRUD (Create/Read/Update/Delete) operations, to HTTP methods (PUT/GET/POST/DELETE) respectively. An important design consideration is limiting the methods to a resource (e.g. no DELETE on /catalog), but it is often not enforced correctly in the implementation. This can lead to undesirable consequences.

VBAAC: Some REST frameworks also intend to implement Verb Based Authentication and Authorization Control (VBAAC) – where different access constraints are bound to different HTTP methods (verbs). For example, GET and POST to /admin are only allowed to specific users. However, most such implementations are insecure.

XML and JSON for data exchange: REST commonly utilizes either JSON or XML in parameters, request and response bodies to exchange information. This data is consumed by the backend services or by the user’s browser. These consumers need special parsers that can deal with these formats, and so would any security technology that intends to secure these formats from malicious inputs.

User Inputs in URL Paths: Whereas vanilla HTTP passes input parameters in URL Query or FORMs, REST passes parameters in different ways like in the URL path and as JSON or XML in the POST request body. The following examples, borrowed from this reference, show a request to get phonebook details of a user. The first is from a traditional HTTP service, the second is for a REST/JSON service, and (just for comparison’s sake) the third for a SOAP service. The UserID parameter is highlighted in RED in all the three cases:

HTTP Example:

GET /phonebook?action=GetUserDetails&UserID=12345 HTTP/1.1
HOST: www.acme.com

JSON/REST Example:

GET /phonebook/UserID/12345 HTTP/1.1
HOST: www.acme.com

SOAP/Web Service Example:

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:body pb="http://www.acme.com/phonebook">
  <pb:GetUserDetails>
   <pb:UserID>12345</pb:UserID>
  </pb:GetUserDetails>
 </soap:Body>
</soap:Envelope>

Notice the lightness of the JSON requests when compared to the SOAP request.

Programmatic Access and Chattiness

That APIs are accessed programmatically is obvious. Another aspect to RESTful applications is their “chatty” nature. A RESTful service invokes granular operations that return simple data about resources, unlike complex, hierarchical information returned in web services. While this means that REST can obtain precise information that is needed, it also means that several more calls are needed to get the same information as compared to web services and applications.

Challenges in Securing REST

So why does traditional web app testing with scanners and pentesting struggle with REST? Lets look at some of the reasons below.

Hard to Determine the Attack Surface (URL space)

In traditional HTTP applications, web application scanners can crawl through the entire URL space by iteratively fetching linked URLs in page sources. However, REST APIs expose resources and transactional operations on them, and most apps make use of only a subset of these, so determining the entire URL space and attack surface is not easy.

Lack of out-of-band API metadata to guide

When testing web services, scanners typically make use of WSDLs to determine the URLs and parameters, which makes fuzz testing easy. However, REST principals discourage such out-of-band schemas metadata.

Hard to Determine Navigation Paths and User Input Locations

Determining URL spaces is further complicated by the fact that REST often uses URL paths for input parameters, which could be injected with malicious data. For example:

https://www.example.com/api/phonebook/UserID/12345

The parameter name (UserID) and value (12345) are in the URL Path. This is a common practice in REST but this completely throws off automated test tools. They have no way of knowing what to do with such elements – whether to consider them as “directories” or to fuzz test them as parameters.

Dynamically Generated URLs

REST-based services often use AJAX as a common design pattern, especially for interactive frontends. This generates URLs dynamically on the clients. Simply parsing the response content to find URLs and injection points is not enough. Vulnerability Scanners (as well as the big search engines) have a hard time crawling through such content.

Lengthy Test Cycles

For longer inputs, REST-based applications often use POST requests with JSON or XML data containing several key value pairs. Testing all of these could be voluminous and require a significantly longer time for fuzz testing.

In the next part of this series, we will see how the Barracuda Web Application Firewall helps mitigate not only these but several other issues relating to REST security.

Scroll to top
Tweet
Share
Share