API Penetration Testing with OWASP 2017 Test Cases

Brief about API Penetration Testing:

API Penetration Testing is one of the favourite attack surfaces, where the attacker can use to gain into further access to the application or server. During the blog reading, I’ve described the OWASP 2017 Test Cases which is applicable for a general application pen test. I’m going to cover basics of the API penetration testing.

This blog all about API pen testing. Basically the blog is devided three diffeent senction as mentioned below.

1. What is API pen testing?
2. Structure of API request and response?
3. Methodology, Tools and Test Case to perform Pen testing?
4. Brief about API Penetration Testing

Details about API Penetration Testing :

API Pen testing is identical to web application penetration testing methodology. Where methods of these type testing remain similar to other web applications with some small changes in the attack hence, we need to look for some standard vulnerabilities that we look for the web application such as OWASP 2017 Top 10: Injection, Access Control, information disclosure, IDOR XSS, and other.

API Security Authentication Basics:

API Authentication and Session Management

When I start looking at the API, I love to see how the API authentication and session management is handled. Developer regularly uses the HTTP basic, Digest Authentication, and JSON Web Token Introduction. Nowadays the oAuth is an easy way to implement authorisation and authentication or sessions management. oAuth provides you with the expirable bearer token, and this makes it more difficult for the attacker to find the security issue in the authentication module. How you can identify the authentication tokens in the API? Answer is lies in the following images caption.

Design or Structure of API

The modern application uses the API for the calling micro-services or performing the actions or monitoring the user’s behaviours. The design or the structure of the API is exposed to the customers or application user. Due to this nature of the API, the attacker can understand the structure of the API and use this information attack API further.

The REST API uses the different processing requests such as GET, POST, PUT, DELETE, HEAD, and PATCH actions. The attacker can modify the request headers for understanding the API and use this understanding to craft entirely working weaponised exploit. The processing request can be altered, and as a best practice of the processing request must be not be tampered or modified. Below is an example of a processing request and also keep eyes on the server reponses for the made requests:

Recommended Tools for API Penetration Testing

Below tools are used during the penetration testing of the API applications. This tool is recommended for manual penetration testing and also tools are freely available over the internet.

1. Swagger-Editor
2. Postman
3. Burpsuite

According to Google : Swagger aides in development across the entire API lifecycle, from design and documentation, to test and deployment.

The purpose of Swager here to convert the OpenAPI document to the JSON or YAML formats and also Swager help you to create the requests of each API endpoints. Further importing the Swager file to the postman, you read the POSTMan documents here. Once we have complete information of Target, request, then we can modify the Host in Postman and Swagger. This setup will help for penetration testing of the API.

How to find vulnerabilities in API?

Learn the attack surface using documentation provided by the customer. A developer guide can give us more details of inside of API. If documentation is not provided or API is deployed in a running server, then we need to capture all API requests using the proxy. Identify the POST/GET or other methods thoroughly in each API requests. After completion of the understanding phase, write down the possible security test cases. Below are basics test cases for the low hanging vulnerabilities.

Hand picked OWASP 2017 Test cases:

1. Observe each parameter in every module of API, understand how the data is transferred from source to destination. Try to play with the parameter by tampering them.
2. Identify if the API has any authorization token if it is having then remove that authorization token and see application response. In some cases, if authorization is not implemented correctly then API might give you access to forbidden assets of application.
3. Analyze and check each module with a different access level of user ex: admin, moderator, normal user.
4. Check whether admin modules can be accessed via the restricted user.
5. Identify the parameters which may vulnerable to IDOR type vulnerabilities such as id=1234 and also look at the cookies for manipulating the Ids.
6. Check injection vulnerabilities by inserting special characters in all parameters in a request and check the response from the server. If you find any stack traces then use the information for further exploitation.
7. Insert greater than, less than (<,>) characters in all parameters and see response whether the application encoding them as > and <. If an application doesn’t escape any special characters then the application may be vulnerable to client-side attacks such as XSS (cross-site scripting).
8. Modify the content-type server header for understanding the XML entity injection attack. Example: change content Application/JSON to application/XML and insert the XML entity payload to find the XML entity injection.

I hope this gives you a basic understanding of the API penetration testing and read more about the Web Services API Penetration Testing part 1 and part 2.