What is API Security?

An Application Programming Interface (API) is the heart of many applications. It provides a connection between computers or between computer programs. API helps to connect to sensitive data such as educational, medical, financial, and personal data for public consumption. APIs provide developers with a powerful interface to the services that an organization has to offer.

In order to ensure an organization’s security, it’s imperative that APIs are compatible with published specifications and are resilient to bad or potential external threats received as input. API security testing ensures systems are secure and protected against potential threats and vulnerabilities. This can include testing for issues such as injection attacks, cross-site scripting (XSS), and improper authentication and authorization. API security testing can be done manually or using automated tools and can be performed both during the development process and after the API has been deployed. 
 
Hence, it’s imperative that API security testing is given ample emphasis by adapting to modern and dynamic API security testing strategies.
 
API security involves ensuring that the API endpoints are protected from external threats. A vulnerable API could lead to Unauthorized Access, Data leakage, Injection Vulnerabilities, Parameter tampering etc.

Why API security is required?

Bitter consequences of an unsecured API may lead to attacks such as data breaches, compliance violations, reputation damage, unauthorized access, legal issues, and business disruption. It is essential to ensure that APIs are secured and protected against potential threats and vulnerabilities.  Leakage of customer data, such data could be sold on the dark web resulting in a trust deficit between customers and organizations causing a probable huge reputational and financial loss for the organization.

Examples of data breaches:

The following API security breaches in popular companies will paint a more realistic picture before you:

  • Information leak of their customers by just using their numbers was found in Airtel API. According to an estimate, there are around 325 million active users of Airtel. Not to say, the result could have been disastrous!
  • In 2019, a bug CVE-2019-5786 was found in the File Reader API. This led to vulnerability in almost all major browsers. Hackers exploited it wildly to target Chrome users!
  • Hostinger, a famous hosting service provider, Attackers were able to access internal API through one of its servers which was hacked. Details of around 14 million clients were stolen!
  • Just Dial, the largest local search engine platform in India, was accused in 2019 of leaking its entire database of customer data of over 100 million users. The leaked information included their names, emails, mobile phone numbers, and date of birth, gender, occupation, photos, and more. Essentially, any piece of data provided through the use of its website, its app, its customer support system, everything, was leaked.
  • In October 2018, a hacker exploited vulnerability in an API used by Flipkart to gain unauthorized access to sensitive customer data, including names, email addresses, and contact numbers of millions of customers

API Security Testing General Checklist:

To ensure your application behaves precisely as expected with the least risk potential to your data, you must test the workflows of any API you use to ensure that the API is safe. For each API security testing we should test the following most common vulnerabilities according to (Open Web Application Security Project) owaspAPI security.

1. Broken Object Level Authorization

When the developer fails to implement a proper authorization process on an API, the API will not properly enforce access controls on resources. This type of security vulnerability is called Broken Object Level Authorization (BOLA). BOLA occurs when the API does not properly restrict access to individual resources, allowing unauthorized access to sensitive information. This vulnerability can be a result of poor implementation of access controls, lack of testing, or failure to update the access controls as the system evolves.

As we can see in the example below, there is no Authorization on the URL endpoint. An attacker can change the endpoint, and as a result, they would have access to the sensitive endpoint “/uptime/s”, which exposes server information in the response. This lack of Authorization on the endpoint is security vulnerability, as it allows unauthorized access to sensitive information.

Prevention:

  • Implementation of auth token such as JWT. (Always use jwt secret with 32 + char and use alphanumeric characters.)
  • Using a centralised authorization solution that can be reused for every sensitive object.
  • Implementation of proper authorization on each resource/ asset.

2. Security Misconfiguration :

This is the most common vulnerability, Leaving default configurations, sample code in the API and exposing the authentication token in response and server-related information in the response body/headers.

In the below example when the user hits on any API endpoint, in the response server version and name is exposed. This information can be used by attackers to exploit known vulnerabilities in the server or launch targeted attacks with specific payloads. This type of security misconfiguration can leave the API and underlying systems open to attack. 

3. Injection

API code injection vulnerability is a security weakness in an API that allows an attacker to insert malicious code into the API by manipulating the input data sent to the API. 

This can cause the API to execute unintended code, potentially leading to a data breach, system compromise or other malicious activities. 

Prevention

  • We can prevent it by limiting the information exposed in the response.
  • Remove the excessive information exposed in the response header (i.e. auth token, server version, name etc.) and in the response body (user id, password or any sensitive information).
  • Change the default configuration.

The injection can be of multiple types like Code Injection, Command Injection, and SQL Injection etc.

In Code Injection, the attacker injects his own code with input data and executes using the API or functionality where the input data is getting processed or rendered. 

In Command Injection, an attacker injects system commands (ie: ls, whoamietc) using the default functionality of the application. 

Below is an example of a command injection attack. In this scenario, the attacker is attempting to send the command “; ls” at the endpoint “uptime/s” As a result, the command is successfully executed and the attacker is able to obtain a list of file names in the current directory on the server. 

Prevention:

This type of attack can be prevented by proper input validation and sanitizationand don’t allow command executions using user-provided input data.

4. Excessive Data Exposure

Excessive data exposure occurs when an API returns more information/data necessary for the intended purpose of the API. This type of vulnerability can occur when the API is not properly configured to limit the amount of data returned in the response, or when the API is not appropriately tied with security measures to protect sensitive data.

In the below example “/token” endpoint should generate only the present user’s token but we can see in the response body, all user’s user ID and password are exposed.

Prevention:
It is important to ensure that the API is adequately configured to limit the amount of data returned and that sensitive data is properly protected to prevent this type of vulnerability.
Test and review all the API responses. The response must only contain what API consumer needs.
API responses must contain proper schemas and error messages. Error messages must be generic.
Proper Testing of all the API responses to check data leakage by accident or exception.

5. Insufficient Logging & Monitoring:

Insufficient logging and monitoring vulnerability means that the system doesn’t keep track of the activities that happen on it or doesn’t keep track well enough. This can make it hard to find out if something bad happens and can make it easier for someone to do something bad without getting caught.

In an organisation logs of transactions and applications must be kept separate data storage and analytics system. If in any case the API system is compromised then information stored on that particular system cannot be trusted. This type of vulnerability can make it difficult to detect and respond to security breaches and other malicious activity.

Prevention:

  • Logs of all (success and error) API request/response information must be stored in a different system. This implies that we should avoid the use of shared drives or tools since manipulation of the compromised system will automatically change data on the storage system.
  • Implement robust logging and monitoring systems for APIs. This may include logging user access attempts, monitoring usage patterns, and implementing proper exception handling. 
  • Regularly review the logs and monitor the API usage to detect any suspicious activity and respond quickly to any security breaches.

6. Lack of Resources & Rate Limiting:

Lack of resource rate limiting is a security vulnerability that can occur in APIs when they don’t set limits on the number of requests that can be made to an endpoint. This can make the API vulnerable to attacks where an attacker floods the API with a lot of requests, making it unavailable to other users. Lack of rate limit on sensitive endpoints i.e.: login, password reset, updates profile etc. helps attackers to perform brute-force attacks that can lead to account takeover of any user. 

For Example:

  • No rate limit on the login API leads to user enumeration and password brute-force attacks, which leads to account takeover. 
  • Suppose we have an application that contains the users’ list on a UI with a limit of 10 users per page. From the below command, users can retrieve the users’ list from server “/API/users?number_of_user_per_page=10”. If an attacker changes parameter “number_of_user_per_page” value to 10000 it will send 10000 API requests to the server and the server may become unresponsive. Similarly, an attacker can increase the numbers and the server may become down due to overload.

Prevention:

To prevent this, it’s important to set limits on the number of requests that can be made to an endpoint in a specific time frame (i.e.: A normal user will never send 1000 requests in a minute), monitor the API usage for unusual patterns and respond quickly to prevent potential attacks. 

7. Broken Function Level Authorization:  

Broken Function Level Authorization (BFLA) occurs when the API does not properly restrict access to individual functions, allowing unauthorized access to sensitive information or functionality.

Organizations where hierarchical permissions system is used. If in any case this flow is broken or incomplete then some people may end up having additional access.  This is called function-level authorization. In the below example, A university website uses the result API which allows teacher to give marks to students and students can only view the result. But due to improper function level authorization a student can also modifyhis/her marks.

Prevention :

Always check for the read/write/update/delete operations access on each resource as per the user role/group/policy.

8. Mass Assignment:  

Mass assignment vulnerability is a security vulnerability that occurs when an API does not properly validate and restrict the parameters that are accepted and used in creating or updating a resource, this vulnerability can be exploited by an attacker to manipulate or change sensitive data without proper authorization. 

If an API endpoint automatically converts user parameters into internal object properties, without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update object properties that they should not have access to.

For Example:

Digilocker uses a “/create” API endpoint to create new users with following request data.

{ “name”:”user1”,”password”:”password1”}

If we modify the request data as following :

{

“name”:”user1”,”password”:”password1”,

“name”:”user2”,”password”:”password1”,

“name”:”user3”,”password”:”password1”,

“name”:”user4”,”password”:”password1”

……………………………………………

……………………………………………

}

AndAPI allows the mass user creation; it falls under mass assignment vulnerability. 

Prevention:

  • To prevent this vulnerability, it’s important to ensure that the API properly validates and restricts the parameters that are accepted and used in creating or updating a resource.
  • Regularly tests and monitors the API to ensure that it is configured correctly and that access controls are being enforced properly.
  • Functions which bind client input into variables or internal objects must be avoided. All the parameters and payloads expected by the server must be defined and validated. 

9. Broken User Authentication: 

If there are any flaws in designing and implementation of identity and access controls such as authentication of user credentials. The Attacker will be able to compromise password, session tokens and get user account information or other details. This is called Broken User Authentication.

For example:

 When a user wants to access any API from APISetu he/she will need a valid Client Id and   secret Key. If in any case by giving an invalid secret Key or without secret key, user is able to access the API then it is Broken User Authentication vulnerability.

Prevention:

To prevent this type of vulnerability, it is important to ensure that the API adequately validates and authenticates user credentials, before giving access to each endpoint. Regularly test and monitor the sensitive API endpoints to ensure that it is configured correctly and access controls are being enforced appropriately.

10. Improper Assets Management:

Improper assets management refers to the failure to effectively control, track, and maintain the resources, equipment, and data that an organization relies on. This can include failing to properly secure sensitive information, neglecting to update or patch software systems, or failing to properly maintain physical assets like buildings and equipment. This can lead to a variety of problems, including security breaches, data loss, equipment failure, and financial losses. To avoid these issues, organizations should implement robust asset management processes and procedures to ensure that all assets are properly tracked, maintained, and secured. This can include regular software updates and backups, regular equipment maintenance, and regular security audits to identify and address vulnerabilities. In the below example we can see staging/testing/development/internal environment is publicly accessible by an attacker, but ideally it should be accessible only by authorised users with whitelisted IP. As we can see normal user with public IP have only access to production environment.

Prevention:

  • Access limiting to production/non-production data.
  • Implementing proper  rate limits, errors, authentication flows, CORS policy triggers, and redirects and documenting them for future reference.

Following few tools that can be used for security testing:  

There are alot of tools out their for security testing in market few of them are following: 

Burp Suite, Postman,Ffuf, SQLmap, Owaspzap(zapproxy), Acunetix, DirBuster, curl etc.

References:

https://owasp.org/www-community/API_security_tools

https://www.redhat.com/en/topics/security/API-security

https://owasp.org/www-community/API_security_tools

Image courtesy of Kusum Rawat | APISetu | Blog

Authors

Leave a Reply

Your email address will not be published. Required fields are marked *