REST API Testing with Qualys Web Application Scanning

With more web applications exposing RESTful (or REST) APIs for ease of use, flexibility and scalability, it has become more important for web application security teams to test and secure those APIs. But APIs (including REST APIs) introduce some behaviors that make it difficult for web application scanners to test them for vulnerabilities.

New features in Qualys Web Application Scanning (WAS) overcome these difficulties.

About REST APIs

With advancement in the design of web applications, newer and newer design choices are coming up for developers of web applications. Web applications have evolved from static web pages to AJAX (Asynchronous Javascript And XML) applications. The latest in the series of advancements is for developers to expose the functionality of their application using REST (REpresentational State Transfer) APIs, whereas earlier forms of web services were exposed using SOAP (Simple Object Access Protocol) or WSDL (Web Service Description Language). RESTful Web services typically expose their functionality via HTTP verbs such as GET, PUT, POST, DELETE and request/response format such as JSON, XML or HTML. Many newer mobile and IoT (Internet Of Things) applications are exposing their functionality using REST APIs.

Understanding the API

The first challenge in testing REST APIs is to understand the endpoints and their characteristics so that all injection points can be tested. REST APIs are not browser-based web applications where a crawler can be used to organically discover various links and forms. However, APIs can be described using a specification file such as Swagger/OpenAPI, WADL (Web Application Description Language), or RAML (RESTful API Modeling Language), or by using a proxy capture from a REST API client.

Using one of these specifications is a convenient way for the scanner to understand the API. In fact Qualys WAS supports Swagger for API vulnerability scanning and added support for Postman Collections in October 2019. However, you may not have a Swagger file or Postman Collection for your API, but instead have a client meant for functional testing of the API. In that case you can still use WAS to scan your API by uploading a Burp proxy capture generated by using the client. Please see Using Burp to Capture REST API Endpoints for more information.

Once the details of the API are understood by the scanner, the next challenge is to systematically test it for vulnerabilities.

How Qualys WAS Tests REST APIs

There are three ways to pass inputs to REST APIs: via URL query parameters, via URL path variables, or via the body of the HTTP request. All three expose potential injection points for malicious payloads, and Qualys WAS can test all of them.

Specifically, Qualys WAS supports fuzzing of requests with GET, POST PUT, and DELETE verbs, and it supports fuzzing of the body of HTTP requests with “Content-Type” as “application/json”. Fuzzing involves passing specially crafted inputs to the API that are designed expose security vulnerabilities. All are described below.

To illustrate the three ways to pass inputs, let’s imagine a hypothetical contact management REST API that exposes a number of services including this one that returns a list of current contacts:

GET request to http://www.example.com/api/v1/contacts

URL Query Parameters

With URL query parameters, inputs are passed as parameters in the URL after the “?”, typically with an HTTP GET request.

Some examples are:

1. GET request to http://www.example.com/api/v1/contacts?sort=firstname
   This returns a list of contacts sorted by firstname.
2. GET request to http://www.example.com/api/v1/contacts?per_page=5&page=5&sort=email
   This provides a list of contacts paginated by 5 contacts per page and sorted by email with content of 5th page.

Qualys WAS uses Parameter Fuzzing to test query parameters (e.g. values of firstname, per_page, page, and sort). Specifically, WAS passes specially crafted parameter values that could result in SQL Injection (QID 150003), Local File Inclusion (QID 150011) or Remote Command Execution (QID 150055).

URL Path Variables

With URL path variables, inputs are passed directly in the URL, often via URL rewriting (where URL parameters are rewritten as URL path variables for better readability and search engine optimization). REST APIs can also include URL path variables that are not the result of URL rewriting. Testing is the same in either case.

Some examples are:

1. GET request to http://www.example.com/api/v1/contacts/50
   This provides details of contact whose ID is 50. This is also an example of a URL rewrite of http://www.example.com/api/v1/contacts?id=50
2. GET request to http://www.example.com/api/v1/contacts/50/notes
   This provides details of all the notes associated with the contact whose ID is 50. A typical response for this request would be [{ “id”: “1”, “body”: “Carpenter with good wooden work ability.”, “contact_id”: “50” }, { “id”: “2”, “body”: “Sample project at Mumbai Bandra.”, “contact_id”: “50” }]
3. GET request to http://www.example.com/api/v1/contacts/50/notes/1
   This provides details of note with ID 1 associated with the contact whose ID is 50. A typical response for this request would be { “id”: “1”, “body”: “Carpenter with good wooden work ability.”, “contact_id”: “50” }

Similar to parameter fuzzing, Path Fuzzing means that WAS passes specially crafted URL path variables that could result in SQL Injection (QID 150003), Local File Inclusion (QID 150011) or Remote Command Execution (QID 150055).

From the above examples, Qualys WAS would fuzz the parameters shown in curly brackets below:

• http://www.example.com/api/v1/contacts/{contact-id}
• http://www.example.com/api/v1/contacts/{contact-id}/notes/{note-id}

More information about how such URLs are tested is provided in Path Fuzzing Challenges.

The Body of the HTTP Request

In this last case, inputs are passed in the body of the HTTP Request (not in the URL), typically with a PUT or POST request.

Some examples are:

1. POST request to http://www.example.com/api/v1/contacts with data { “firstname”: “John”, “lastname”: “Smith”, “email”: “jsmith@example.com”, “phone”: “415 555 2671”, “favorite”: “0” }
   This request adds a new contact with the details given in the data part.
2. PUT request to http://www.example.com/api/v1/contacts/51 with data { “firstname”: “John”, “lastname”: “Smith”, “email”: “jsmith@example.com”, “phone”: “415 555 2671”, “favorite”: “1” }
   This request modifies the contact with ID 51 by changing the value of the favorite field to 1.

Fuzzing JSON Input in the Request Body: Qualys WAS fuzzes the body of these requests when the body is in JSON format. The fuzzing works in the same way as explained in Fuzzing JSON Input For Vulnerabilities Using Qualys WAS.

Additional Challenges

Authentication: Typical web applications use form/cookie or server-based authentication while REST APIs use a variety of other authentication methods such as certificate, API_KEY or authentication token.

The current REST API testing in Qualys WAS supports two kinds of authentication methods:

• Server Auth – This includes Basic, NTLM and Digest authentication methods. This is similar in behavior to how these methods are used in traditional web applications.
• API_KEY – This supports passing an API_KEY in a header in all the requests that are created by WAS. This method is useful in testing REST APIs that take a custom header to identify a user/session.

Rate Limiting: Traditional web applications do not have any limit on the number of requests performed by test application during a fixed interval and it completely depends on how much load the server is capable of handling. While in case of RESTful Web services, server will limit the number of API calls done during a fixed interval and if the requests exceed the limit, server will typically send HTTP response code 429 (Too Many Requests). We recommend that web application security teams check if rate limiting is blocking their scans.

Free Trial

See how you can test your APIs for vulnerabilities by starting a trial of Qualys Web Application Scanning.