What is REST API?
REST (Representational State Transfer) is an architectural style that can be used to communicate with web services. In many ways 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. In fact many mobile web applications communicate with a RESTful API at the backend to communicate with the online service.
In this document:
What are the Differences Between a Web Service and 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
- POST - Create a resource
- GET - Retrieve a resource
- PUT - Change the state of a resource or update
- DELETE - Remove or delete a resource
The Challenges of Scanning REST API Interfaces
Unlike RPC and others, REST can be consumed and understood by humans because of its simple structure. For example many REST-based web services can provide a response in CSV, 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
As a matter of fact, at the moment of writing this document there is no standard for REST API, as there is for WSDL and other similar protocols. So far most RESTful web services have their unique documentation, which again can be easily read by humans but is of no value to automated web vulnerability scanners.
Using Parameters in URLs
Another challenge automated scanners have when automatically 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:
This can also be the case when scanning web applications, but the Netsparker web application security scanners have a heuristic URL Rewrite technology that can automatically identify parameters in the URLs and scan them. Though in case of a REST API things work a bit differently.
How to Scan a RESTful Web Service for Vulnerabilities
There are three different methods which you can use to scan a RESTful API with both the Netsparker Desktop and Netsparker Cloud web application security scanner. You can:
- Import a Swagger or WADL definition file manually,
- Netsparker can automatically discover a RESTful API during crawling and scans it,
- Manually import RAW HTTP request(s).
Below is an explanation of how each of the methods work.
Import the SWAGGER or WADL Definition Files Manually
When you import a Swagger or WADL definition file, the Netsparker web security scanner will parse the definition file and create a link for every resource available in the API. To import a Swagger or WADL definition file you should:
- Navigate to the Imported Links in the Start a New Website or Web Service Scan dialogue box,
- Click Import and select the definition file.
Once the scanner imports all the links and parameter you can see them in the list of Imported Links as seen in the below screenshot.
During the import the web vulnerability scanner will automatically generate the URL Rewrite rules to scan every parameter in the RESTful API. Below is a screenshot of the automatically generated URL rewrite rules in Netsparker:
Note: When importing a RESTful web service definition file in Netsparker Cloud the URL Rewrite rules are not shown in the start a New Scan dialogue, but they will be reported in the Knowledge Base node once the scan is finished.
Authentication and RESTful Web Services
Similar to when scanning other web applications and services, authentication can be configured during the scan from the Authentication section.
Automated Discovery of RESTful API during Crawling
The Netsparker web application security scanner will automatically import, crawl and scan a REST web service should it be identified during a website security 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, as seen in the below screenshot.
The below screenshot is from Netsparker Cloud, when it identifies a RESTful web service.
Import RAW HTTP Request(s) Manually
In cases where the 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. Below is a list of supported proxy files:
- Fiddler session archives (*.saz)
- Burp log files (*.xml)
- Paros log files (*.txt)
- HTTP archive files (*.har)
Note that when using this method the scanner won’t automatically generate the URL rewrite rules, hence you have to configure them manually for the scanner to find all the parameters.