To start with testing API, here are the following tools we require to test API:
Let’s start with the test cases while also understanding its purpose:
Note: We are assuming that we have the API collection uploaded on the tool Postman or Swagger UI.
Check for Excessive Data Exposure: The purpose of this test case is to find out the endpoints which discloses a lot of information in the response. The API responds with the entire object rather than only sending the necessary information which is the main cause of this issue.
For example - In the case of a blog website, where a lot of users have commented, a response containing personal information of the user which might include their email ID, phone number, username, UserID, etc is unnecessary. This leads to excessive data exposure. Similarly, there might be other API calls which are disclosing unnecessary information in the response.
Token Analysis and Attacks: This involves analyzing the randomness of the API token which is present in the request of the API calls. Tokens might also be encoded in a data format which can be easily decoded. In case of tokens using Signatures, signature attacks can be performed where signatures can be either manipulated or removed.
For example - A token of 5 digits can be easily guessable by brute forcing but a JWT token is not that easily guessable as it contains a signature.
Brute-Force on authentication endpoints: With a list of usernames and passwords, an authentication endpoint like login can be brute forced using tools like Burpsuite or any other fuzzing tool like wfuzz, ffuf.
Broken Object Level Authorization: Assume there are two users, UserA and UserB. When accessing API’s, they use parameters or resource ID to call the specific resources, these values can be manipulated in case there is no validation present. Resources of userA can be accessed by userB by manipulating the value of the API call.
For example - Assume there is a web application that provides an API endpoint for users to retrieve their account information. The API endpoint might look something like this:
GET /api/accountInfo?userId=01
In a secure application, this request should be accompanied by proper authentication and authorization checks to ensure that the user making the request (identified by the userId parameter) has the necessary permissions to access the requested account information. Now, let's consider a scenario where there is a BOLA vulnerability in the application, specifically in the accountInfo API endpoint. The application fails to properly validate the user's authorization to access the requested account information.
Normal Request by UserA:
UserA, with userId=01, makes a legitimate request to retrieve their own account information:
GET /api/accountInfo?userId=01
Manipulated Request by UserB:
UserB notices that the application does not properly validate authorization for the accountInfo endpoint and decides to manipulate the userId parameter to access UserA's account information:
GET /api/accountInfo?userId=02
In this manipulated request, UserB changes the userId parameter to the ID associated with UserA's account. Due to the BOLA vulnerability, the application doesn't check whether UserB has the proper authorization to access UserA's account information.
As a result, UserB is able to retrieve sensitive details belonging to UserA, such as their account balance, transactions, or other private information. This scenario illustrates the risk of BOLA vulnerabilities, where inadequate object-level authorization checks can lead to unauthorized access to sensitive data by manipulating parameters or resource identifiers. Addressing such vulnerabilities involves implementing proper authorization checks to ensure that users can only access resources they are authorized to view or modify.
Broken Function Level Authorization: BFLA vulnerabilities are common for requests that perform actions of other users. These requests could be lateral actions or escalated actions. Lateral actions are requests that perform actions of users that are the same role or privilege level. The main thing we are looking for are functional requests.
For Example - Consider an online banking application where users can transfer money to other accounts. Each user has a unique user ID associated with their account. The application uses a functional request like the following to initiate a fund transfer:
POST /transferFunds HTTP/1.1
Host: examplebank.com
Content-Type: application/json
{
"recipientAccountId": "123456789",
"amount": 100.00
}
In a secure application, this request should include proper authentication and authorization checks to ensure that the user making the request has the necessary permissions to transfer funds. However, in a scenario with a BFLA vulnerability, these checks are improperly implemented. Now, let's assume there is a BFLA vulnerability in the application, specifically in the transferFunds functionality. An attacker, who is a regular user with a standard account, discovers this vulnerability and decides to exploit it.
Lateral Action (Same Role or Privilege Level):
The attacker, being a regular user, decides to perform lateral actions by transferring funds on behalf of another regular user with a different account (let's say account ID 111).
The attacker sends a request similar to the one above but changes the recipientAccountId to the account they want to target (111).
POST /transferFunds HTTP/1.1
Host: examplebank.com
Content-Type: application/json
{
"recipientAccountId": "111",
"amount": 50.00
}
Escalated Action (Different Role or Privilege Level):
Expanding on the scenario, the attacker realizes that the lack of proper authorization checks allows them to perform escalated actions, such as transferring funds to an administrative account (e.g., admin123).
The attacker sends a request to transfer funds to the administrative account.
POST /transferFunds HTTP/1.1
Host: examplebank.com
Content-Type: application/json
{
"recipientAccountId": "admin123",
"amount": 1000.00
}
In both cases, the lack of proper function-level authorization checks enables the attacker to perform actions that they should not be allowed to do, either within the same role or even escalating to a higher privilege level. This represents a BFLA vulnerability that needs to be addressed through proper authorization controls in the application.
CORS Misconfiguration: In this test case, observe the request and response headers. If we add a header of Origin and assign it a random URL, and if the random URL is getting reflected into the response in Access-Control-Allow-Headers and Access-Control-Allow-Credentials is having the value True, then the API endpoint might be vulnerable to CORS Misconfiguration. CORS allows resources from different origins on the web application, if the server is not configured properly, data of sensitive endpoints can be exposed using CORS misconfiguration.
Server Side Request Forgery: In case of an API call taking a URL or a path as an input is not validated, an attacker can supply their own input, in the form of a URL, to control the remote resources that are retrieved by the targeted server. When you have control over what resources a server requests then you can gain access to sensitive data or worse completely compromise a vulnerable host.
Injection attacks: Injection attacks on APIs, such as SQL Injection (SQLi), Cross-Site Scripting (XSS), and Command Injection, pose significant threats to web application security. In SQL Injection, attackers exploit vulnerabilities by injecting malicious SQL queries into API input fields, potentially gaining unauthorized access to databases. XSS involves injecting malicious scripts into API responses, leading to the execution of unauthorized scripts on the client side and posing risks like session hijacking. Command Injection, on the other hand, targets operating system commands within API input, allowing attackers to execute unauthorized commands on the server, potentially leading to system compromise.
Tools necessary for API testing are:
BurpSuite -
This tool plays an important role in manipulating requests and responses as it acts as a proxy between client and the server.
This tool also helps in performing Brute Force attacks, helps us analyze entropy in tokens and helps us perform trial and error on requests.
Postman -
This tool helps us with grouping of API collections and various methods of importing API documentations. We can capture requests using the proxy present in this tool.
We can set up test cases to know if the API collection requests and responses satisfy given conditions. We can run all the requests at the same time by running the entire collection to analyze responses and run test cases on the API call responses.
This tool helps us assign variables to the request so that changes can be made throughout the collection rather than changing values in all the requests manually.