In-brief: RESTful application program interfaces (APIs) are a key ingredient to building powerful, scalable web-based applications. But they can also open the door to web-based attacks, while also baffling traditional penetration testing tools and processes. In this article, Barracuda’s Neeraj Khandelwal explains why.
Editor’s note: This is the second in a three-part series on securing REST APIs. You can read the first installment here.
In our previous post, we alluded to new challenges in securing Representational State Transfer (REST) application program interfaces (APIs). In this post, we’re going to dive into some of the details. Let’s begin with some typical aspects of REST that have bearings on API security.
Use of Hyper Text Transfer Protocol Secure (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 Create Read Update Delete (CRUD):
REST-based services map CRUD 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.
Verb Based Authentication and Access Control (VBAAC):
Some REST frameworks also intend to implement 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.
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 Simple Object Access protocol (SOAP) service. The UserID parameter is highlighted in RED in all the three cases.Notice the lightness of the JSON requests when compared to the SOAP request.
GET /phonebook?action=GetUserDetails&UserID=12345 HTTP/1.1
GET /phonebook/UserID/12345 HTTP/1.1
SOAP/Web Service 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 application testing with scanners and penetration testing struggle with REST? Lets look at some of the reasons below.
- It is 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.
- There is a lack of out-of-band API metadata to use as a guide
When testing web services, scanners typically make use of Web Service Definition Language (WSDL) to determine the URLs and parameters, which makes fuzz testing easy. However, REST principals discourage such out-of-band schemas metadata.
- It is 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 front ends. 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 using web application security helps mitigate not only these but several other issues relating to REST security.
Now that we’ve discussed some of the REST features that affect security, we’re ready to talk about how to use good web application security design to help secure REST APIs and eliminate security problems resulting from them. In our next installment, we will examine how web application security design can help secure REST APIs including de-obfuscations, and protocol sanitization and other checks. Stay tuned for discussion in post coming soon to Security Ledger!