In this blog post I’m going to describe 3 different ways to scan REST APIs using the new version 10 of Acunetix Web Vulnerability Scanner.
1. REST API automatically discovered via Acunetix DeepScan
Let’s start with a simple web application that is using REST. It only has one page and the contents of this page are listed below:
As you can see, everything is happening via JavaScript. The code is making an AJAX call to a REST API using the URL /api/user and the method PUT and posting some JSON data towards this API.
Let’s see what is happening if we crawl this application without Acunetix DeepScan:
Because the API call is performed via JavaScript, the REST API is not discovered. The crawler didn’t find anything and the web application cannot be scanned properly.
Now, let’s crawl with Acunetix DeepScan enabled.
Things are much better now. DeepScan intercepted the AJAX call to the REST API, figured out it is using a JSON payload, parsed the JSON and created an input group for testing all the JSON fields.
So, if the REST API is called from the JavaScript code using AJAX calls, Acunetix WVS will automatically detect the request and scan the JSON parameters.
2. REST API automatically discovered via OPTIONS method
But what about more complex REST APIs that are only partially called from JavaScript code using AJAX calls? Sometimes Acunetix DeepScan can find only a small subset of the REST API calls because not all API calls are used from JavaScript. But we want to scan all the REST API calls. How can we do that?
Some REST frameworks make this process very simple. For example, the popular framework Jersey (Jersey RESTful Web Services framework is an open source, production quality, framework for developing RESTful Web Services in Java). When queried via the OPTIONS method, Jersey and other frameworks will provide the WADL definition in the response.
The Web Application Description Language (WADL) is a machine-readable XML description of HTTP-based web applications (typically REST web services). WADL models the resources provided by a service and the relationships between them.
Acunetix WVS can parse this WADL definition and make a list of all the REST APIs and how to invoke them.
Here is a sample WADL response returned by Jersey when queried via the OPTIONS method:
Acunetix WVS will automatically parse the WADL file, and use it to figure out the resource paths, method definitions and representation media types, and create input groups for everything so they can be scanned properly.
It can even find more complex vulnerabilities in REST APIs, such as the stored XSS (cross-site scripting) vulnerability identified in the query parameter customer_name shown below.
3. REST API parsed from application.wadl (automatically or manually)
The last way to scan REST APIs using Acunetix WVS is via WADL files that are either found automatically by crawler or manually passed to the crawler via the Advanced crawling options section from the Scan Wizard.
The first option: the crawler will automatically probe for application.wadl files in each directory and if it finds a valid WADL file it will automatically parse it. In addition, the scanner will also parse all .WADL files it finds during crawling, so if the WADL file is linked to, it will also work.
The second option: In Acunetix WVS version 10 it’s possible to help the crawler by passing links and HTTP requests via a variety of options (these will be described in a separated post). The simplest way is to create a text file that contains a list of links (one link per line).
For example, I’ve created a file links.txt that contains 2 links to different WADL definition files.
http://bld01/restWADL/first.wadl
http://bld01/restWADL/second.wadl
Then, in the Scan Wizard I’ve ticked the “Show advanced options in the scan wizard” checkbox.
And, configured the text file containing the text file with the links to the WADL files.
At this point, the scanner has all the information it needs to find the WADL files, parse them and scan the REST APIs properly.
Get the latest content on web security
in your inbox each week.