REST (Representational State Transfer) is an architectural style that can be used to communicate with web services. REST has a lot in common with protocols such as SOAP. It is used as a communication mechanism between two applications, or between an application and an online service. Many mobile web applications communicate with a RESTful API at the backend in order to communicate with the online service.
You can scan a RESTful API Web Service in both Netsparker Enterprise and Netsparker Standard editions.
Differences Between a Web Service and a REST API
Many web services rely on complex communication mechanisms such as SOAP, RPC and CORBA. REST uses the standard HTTP methods for all four CRUD (Create, Read, Update, Delete) operations.
Commonly Used HTTP Methods (Verbs) in REST API
This table lists the commonly used HTTP methods in REST.
Create a resource
Retrieve a resource
Change the state of a resource or update it
Remove or delete a resource
The Challenges of Scanning REST API Interfaces
Unlike RPC and others, REST can be easily consumed and understood by users because of its simple structure. For example, many REST-based web services can provide a response in JSON or XML format. But this same benefit is what makes it very difficult for an automated web vulnerability scanner to crawl and attack.
Lack of Standards for REST
There is no consistent standard for REST API, as there is for WSDL and other similar protocols. Most RESTful web services have their own documentation, useful for developers but useless to automated web vulnerability scanners.
A number of projects aim to standardize the REST API:
Using Parameters in URLs
Another challenge automated scanners encounter when scanning RESTful web services for vulnerabilities is that REST APIs use parameters in URLs.
For example in the HTTP GET request below, 123 is a parameter and not a directory in the web application:
- GET http://www.example.com/rest-api/products/123/
Scanning a RESTful API Web Service for Vulnerabilities
There are three ways to scan a RESTful API. Each is outlined below:
- Importing the Definition Files (Swagger or WADL) Manually
- Automating the Discovery of RESTful APIs During Crawling
- Importing RAW HTTP Requests Manually
Importing the Definition Files Manually
When you import an OpenAPI (formerly Swagger), WADL or WordPress REST API definition file, the Netsparker web application security scanner will parse the definition file and create a link for every resource available in the API. To import a Swagger, WADL or WordPress REST API definition file you should:
How to Import the OpenAPI (formerly Swagger), WADL or WordPress Definition Files Manually in Netsparker Enterprise
- Log in to Netsparker Enterprise.
- From the main menu, click Scans, then New Scan. The New Scan window is displayed.
- From the Scan Settings section, click Imported Links.
- From the Import Links dropdown, select an appropriate API definition file type. The Open dialog is displayed.
- Select a file to import and click Open. Repeat for as many items as you wish.
- Once Netsparker Enterprise imports all the links and parameters, they are displayed in a list in the Import Links section.
During the import, URL Rewrite Rules will automatically be generated, so that every parameter in the RESTful API is scanned.
When importing a RESTful web service definition file in Netsparker Enterprise the URL Rewrite rules are not shown in the Start a New Scan window, but they will be reported in the Knowledge Base node, either once the scan is finished or during the scan.
How to Import the OpenAPI (formerly Swagger), WADL or WordPress Definition Files Manually in Netsparker Standard
- Open Netsparker Standard.
- From the Start a New Website or Web Service Scan dialogue box, click Imported Links. The Imported Links options are displayed.
- From the Import From File dropdown, select OpenAPI (formerly Swagger), Web Application Description Language or WordPress REST API. The Import Links dialog is displayed.
- Select the definition file.
- Click Save.
- Once the scanner imports all the links and parameters you can see them in the list of Imported Links as seen in the below screenshot.
During the import, URL Rewrite rules will automatically be generated, so that every parameter in the RESTful API is scanned.
When importing a RESTful web service definition file in Netsparker Enterprise the URL Rewrite rules are not shown in the Start a New Scan dialogue, but they will be reported in the Knowledge Base Nodes once the scan is finished.
Automating the Discovery of RESTful APIs During Crawling
Similar to when scanning other web applications and services, authentication can be configured from the Authentication tab.
How to Automate the Discovery of the RESTful API During Crawling
The Netsparker web application security scanner will automatically import, crawl and scan a REST API web service, if it is identified during a scan. Once the scanner identifies the definition file, it will automatically generate the URL Rewrite rules so it can scan all the parameters in the web service.
When the scanner identifies a RESTful API web service during a crawl it will also report it in the Knowledge Base node. This is what the REST APIs node looks like in the Knowledge Base section of the Technical Report in Netsparker Enterprise.
This is what REST APIs look like in the Scan Summary Dashboard in Netsparker Standard.
Importing RAW HTTP Requests Manually
In cases where the OpenAPI (formerly Swagger) or WADL definition files are not available, or the RESTful API cannot be identified during the crawl of a web application, you can import the API's links via RAW HTTP files.
You can capture the HTTP requests via a third party proxy tool such as Fiddler and import them before starting the scan. Here is a list of supported proxy files:
- Burp Saved Items (*.xml)
- Fiddler session archives (*.saz)
- HTTP archive files (*.har)
- Paros log files (*.txt)
Note that when using this method the scanner will not automatically generate the URL rewrite rules. Configure the URL Rewrite Rules manually.
Netsparker supports Burp's XML format.
How to Import RAW HTTP Requests Manually
The procedure for importing these tools manually is the same as that for importing SWAGGER or WALD (see Importing the Definition Files Manually).