How to Test a REST API
REST API is a collection of URLs, in which HTTP calls to URI and in response, it serves JSON or XML data. REST API is different than UI based application. REST API is just an endpoint. To perform successful attacks on the REST API, we have to collect information about the endpoint, good data, messages and parameters. The parameters are not standard, it may be part of URL or may be a constant header.
REST APIs are vulnerable to common and well known OWASP attacks such as injection, CSRF, Cross site script, XMLExternalEntity, etc.
Hackazon application has REST API module integrated in the android application. User can install android application in the Android Emulator and setup a proxy. To capture REST traffic, user can use ZAP Proxy tool.
Below, you can see the proxy setup both in the ZAP Proxy and Android Emulator.
After setting up the proxy, users can start browsing the application to capture the REST data.
To start with the manual or automated scanning it is important to collect full requests using a proxy tool as application based on REST API may not be provide actual attack surface. Based on the collected requests, attack surface will be determined such as constant ids, id passing as part of URL, tokens, methods, etc.
Test REST API manually using ZAP Proxy
Hackazon mobile application has used REST APIs in some the forms. Following screenshot shows that application is using REST API to fetch the orders from application.
This request has two parameters “page” and “per_page”. The “per_page” parameter is vulnerable to Blind SQL injection. Following example demonstrates the time based blind sql injection in the REST API. In the first request, we have injected (SELECT * FROM (SELECT(SLEEP(5)))a)#. It will cause the 5 seconds of delay from the server.
In second request, we injected 10 seconds of delay. As highlighted, we are getting 10 seconds of delay in the response. Hence, we can conclude that this parameter is vulnerable to blind sql injection.
Blind SQL injection
URL: http://192.168.1.108/api/category?page=1&per_page=2 Parameter name: per_page Attack values:
1000;%20select%20sleep%20(5);#1000;%20select%20sleep%20(10);#1000;%20select%20sleep%20(15);#
Request 1
Response 1
Request 2
Response 2
Request 3
Response 3
Results
Hackazon application has user’s profile updation REST api, which is vulnerable to blind sql injection. This api is using PUT method to update user’s profile.
To identify blind sql injection, first we injected a single quote ('). As a result sql query got unbalanced and application threw an error with 500 (Internal Server Error) with stack trace as shown in Request and Response [] and []. To balance a query we injected two single quotes ('') and user profile was submitted successfully.
SQL injection
URL: http://192.168.202.131/api/user/1 Method: PUT Parameter name: first_name Attack values:
test'test''
Request 1
Response 1
Request 2
Response 2
Cross Site Scripting
URL: http://192.168.1.108/api/user/1
Method: PUT
Parameter name: first_name
Attack value: <script>alert(1)</script>
User profile page is vulnerable to Cross site scripting attack. We injected a script tag in “first_name” parameter value. In result, we got an echo in response from server. But, application will not execute the script as it is not using any HTML component. Though, injected script will execute in the browser.
Request 1
Response 1
Resulting Profile page in web browser
To test REST API using AppSpider (DAST)
Testing REST API is very challenging task. Most of the DAST tools needs training mode to test the REST APIs because APIs are using complex JSON, XML or gwt structure which against the normal query string parameter. AppSpider has ability to test identify JSON, XML, gwt or AMFs parameter and its value. Hence, It is not needed any pre training session to test such modules. Also, AppSpider accepts variety of pre recorded traffic.
For instance, we are using Burp proxy tool to record traffic. Record application traffic in the burp proxy and save item in XML data.
Now, open AppSpider and create a Scan Configuration. Click on the next button.
Check the “Recorded Traffic” as we will supply a xml file that we have created earlier and click on the next button.
Click on the ”Add File” button. Import created burp xml file and click on the “Click here to view file content”.
Check the “Restrict scan to recorded traffic” option.
Click on the “Save and start” button and AppSpider will start the scanning.
AppSpider will take few minutes to complete the scan and it will generate a report based on the vulnerabilities found.
AppSpider has completed a scan. It has found 3 SQL injections and 26 reflections during the vulnerability scan.
AppSpider has generated a HTML report.
AppSpider found a SQL injection on “per_page” of http://192.168.1.108/api/category page. One can see the attack request by expanding Attack Traffic.
In another example, AppSpider has found another SQL injection on “page” parameter of http://192.168.1.108/api/product page. Further details of vulnerability can be seen by expanding Attack Traffic.
