Hello to all penetration tester. this guide is designed to help penetration testers understand the process of API penetration testing, identify common vulnerabilities, and apply effective testing techniques.
Table of Contents
- Understanding API Penetration Testing
- Preparation Steps
- Reading API Documentation
- Testing User Authentication
3. Common API Vulnerabilities
- Information Disclosure
- BOLA (Broken Object Level Authorization)
- Broken User Authentication
- Excessive Data Exposure
- Lack of Resources and Rate Limiting
- BFLA (Broken Function Level Authorization)
- Mass Assignment
- Security Misconfiguration
- Resource Enumeration
- API Injections
- Improper Asset Management
- Business Logic Vulnerability
1. Understanding API Penetration Testing
API penetration testing is the process of evaluating the security of APIs by simulating attacks to identify vulnerabilities. This guide will walk you through the steps involved in conducting a thorough API penetration test.
2. Preparation Steps
2.1. Try to find API documentation and read it.
Before starting your penetration test, familiarize yourself with the API documentation. This will help you understand the endpoints, authentication methods, and expected input/output formats.
Note: If you can’t find API documentation, then you can create it using Postman or Burp Suite and FUZZ by ffuf, dirbuster, wfuzz and etc.
2.2. Testing User Authentication
Determine how the client wants to handle testing for authenticated and unauthenticated users. This is crucial for understanding the scope of your testing.
• Authenticated Testing: Test with valid credentials to assess user permissions.
• Unauthenticated Testing: Attempt to access endpoints without authentication to identify potential security flaws.
3. Common API Vulnerabilities
3.1. Information Disclosure
APIs may inadvertently expose sensitive information through error messages or verbose responses.
Example:
• Verbose Error Messages: An API returning stack traces or database errors can provide attackers with valuable information.
• Response Header value: An API response may return some headers such as Server, X-Powered-By, etc., and disclose some information about the web server or web application framework.
3.2. BOLA (Broken Object Level Authorization)
BOLA vulnerabilities occur when users can access resources they are not authorized to access. Let’s take an example: Suppose an attacker signs up on an API provider. When he retrieves his account information, he sees an interesting parameter.
http://redacted.tld/api/v2/userinfo/1253
He assumes that the number at the end is his user ID, so he tries to enter 1 instead of his ID.
http://redacted.tld/api/v2/userinfo/1
Surprisingly, he is able to retrieve all the information about the admin’s account, and this is BOLA.
How to Prevent:
• Implement a proper authorization mechanism that relies on user policies and hierarchy.
• Use the authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses input from the client to access a record in the database.
• Prefer the use of random and unpredictable values as GUIDs for record IDs.
• Write tests to evaluate the vulnerability of the authorization mechanism. Do not deploy changes that make the tests fail.
3.3. Broken User Authentication
Any weak authentication mechanisms can allow attackers to bypass security controls.
Example:
• Permits weak passwords.
• Allows users to change their email address, current password, or perform any other sensitive operations without requesting for password confirmation.
• Sends sensitive authentication details, such as authentication tokens and passwords, in the URL.
• Uses plain text, non-encrypted, or weakly hashed passwords.
How to Prevent:
It is recommended to implement multi-factor authentication, password policies, and session management controls.
• Ensure that you are aware of all possible authentication flows for the API. Ask your engineers about any flows you may have missed.
• Familiarize yourself with your authentication mechanisms. Make sure you understand how they are used and what they entail.
• Do not attempt to create new methods for authentication, token generation, or password storage. Instead, adhere to established standards.
• Treat “forgot password” endpoints as login endpoints in terms of protection against brute force attacks, rate limiting, and lockouts.
• Require re-authentication for sensitive operations, such as changing the account owner’s email address or 2FA phone number.
3.4. Excessive Data Exposure
APIs should only return the necessary data. Excessive data exposure can lead to information leaks. In other words, data must be filtered on the backend, not on the client side.
Example:
• Review API responses to ensure that only required fields are returned.
How to Prevent:
• Never rely on the client side to filter sensitive data.
• Review the responses from the API to ensure they contain only legitimate data.
• Backend engineers should always ask themselves “who is the consumer of the data?” before exposing a new API endpoint.
• Avoid using generic methods such as to_json() and to_string(). Instead, select specific properties you truly want to return.
• Classify sensitive and personally identifiable information (PII) that your application stores and works with, reviewing all API calls that return such information to determine if these responses pose a security issue.
3.5. Lack of Resources and Rate Limiting
API requests consume resources such as network, CPU, memory, and storage. The amount of resources required to satisfy a request greatly depends on the user input and endpoint business logic. Also, consider the fact that requests from multiple API clients compete for resources.
Example:
• Check rate limit
• Check limitation on Upload
• Check limitation on adding a record to the database
Note: If you find a rate limit mechanism, then try to bypass it.
How to Prevent:
• Docker makes it easy to limit memory, CPU, number of restarts, file descriptors, and processes.
• Implement a limit on how often a client can call the API within a defined timeframe.
• Notify the client when the limit is exceeded by providing the limit number and the time at which the limit will be reset.
• Add proper server-side validation for query string and request body parameters, specifically the one that controls the number of records to be returned in the response.
3.6. BFLA (Broken Function Level Authorization)
This vulnerability arises when users can access functions they are not authorized to use. The best way to find broken function level authorization issues is to perform a deep analysis of the authorization mechanism while keeping in mind the user hierarchy, different roles or groups in the application, and asking the following questions:
• Can a regular user access administrative endpoints?
• Can a user perform sensitive actions (e.g. creation, modification, or deletion) that they should not have access to by simply changing the HTTP method (e.g. from GET to DELETE)?
• Can a user from group X access a function that should be exposed only to users from group Y, by simply guessing the endpoint URL and parameters (e.g. /api/v1/users/export_all)?
How To Prevent:
• The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.
• Review your API endpoints against function level authorization flaws, while keeping in mind the business logic of the application and groups hierarchy.
• Make sure that all of your administrative controllers inherit from an administrative abstract controller that implements authorization checks based on the user’s group/role.
• Make sure that administrative functions inside a regular controller implement authorization checks based on the user’s group and role.
3.7. Mass Assignment
Mass assignment vulnerabilities occur when an API allows users to modify fields that should not be editable.
Example:
• Testing Mass Assignment: Use the registration, profile editing, and reset password endpoints to attempt to modify or add parameters like “role”, “email”, “verify”, or etc.
How to Prevent:
• Whitelist only the properties that should be updated by the client.
• Use built-in features to blacklist properties that should not be accessed by clients.
• If applicable, explicitly define and enforce schemas for the input data payloads.
3.8. Security Misconfiguration
Misconfigurations can lead to various security issues.
Example:
• Checking for Verbose Errors
• Poor Transit Encryption
• Lack of Input Sanitization
How to Prevent:
• A repeatable hardening process leading to fast and easy deployment of a properly locked down environment
• Limit accessible HTTP verbs and enable a proper CORS policy.
• Use customized Errors
3.9. Resource Enumeration
Resource enumeration is the process of identifying and exploiting unnecessary or exposed resources within an API. These resources can include:
1. Unnecessary HTTP Methods: APIs may expose HTTP methods like GET, POST, PUT, DELETE, and others that are not intended for public use. This can allow attackers to access or modify data that should be restricted.
2. Default Credentials: APIs may expose default credentials, such as default usernames and passwords, which can be used to gain unauthorized access to the API.
How To Prevent:
1. Implement Proper Configuration: Ensure that APIs are configured to only allow necessary HTTP methods and restrict access to sensitive endpoints.
2. Use Security Controls: Implement security controls like authentication, authorization, and rate limiting to prevent unauthorized access.
3. Thorough Testing: Conduct thorough security testing to identify and remediate exposed resources.
4. Regular Audits: Regularly audit APIs for exposed resources and ensure that security settings are up to date.
3.10. Injections
API injections are a type of vulnerability that occur when an API is susceptible to malicious input that can be used to manipulate the API’s behavior. This can lead to unauthorized access, data theft, or even system compromise. In this guide, we will explore the different types of API injections and how to identify and mitigate them. This can happen in various parts of an API request, including:
1. API Keys: Malicious actors can inject API keys to gain unauthorized access to the API.
2. Tokens: Tokens can be injected to bypass authentication or authorization mechanisms.
3. Headers: Headers can be injected to manipulate the API’s behavior or gain unauthorized access.
4. Parameters: Parameters can be injected to manipulate the API’s behavior or gain unauthorized access.
Some Types of API Injections:
1. SQL Injection: This occurs when an API is susceptible to SQL injection attacks. Attackers can inject malicious SQL code into the API’s queries to gain unauthorized access to the database.
2. XSS (Cross-Site Scripting): This occurs when an API is susceptible to XSS attacks. Attackers can inject malicious scripts into the API’s responses to execute malicious code on the client-side.
3. Cross-API Scripting (XAS): This occurs when an API is susceptible to XAS attacks. Attackers can inject malicious scripts into the API’s responses to execute malicious code on the client-side.
4. OS Command Injection: This occurs when an API is susceptible to OS command injection attacks. Attackers can inject malicious commands into the API’s requests to execute system commands.
How To Prevent:
1. Input Validation: Validate all input data to prevent malicious input from being injected.
2. Sanitization: Sanitize all input data to remove any malicious code or characters.
3.11. Improper Asset Management
Improper asset management refers to the lack of proper control and oversight over API assets, including versions, environments, and access controls. This can happen when:
1. API versions are not properly managed: Old or previous API versions may be running unpatched, exposing vulnerabilities.
2. API environments are not clearly defined: It may be unclear which environment the API is running in (e.g., production, staging, test, development), leading to potential misconfigurations.
3. Access controls are not properly implemented: It may not be clear who should have network access to the API (e.g., public, internal, partners), leading to unauthorized access.
4. Documentation is lacking or outdated: Without proper documentation, it can be difficult to understand the purpose, data flow, and other critical aspects of the API.
Note: Sometimes if you test endpoints like /internal/ after or before api version such as */v2/*, you can access administrative functions.
How to Prevent:
• Inventory all API hosts and document important aspects of each one of them, focusing on the API environment (e.g., production, staging, test, development), who should have network access to the host (e.g., public, internal, partners), and the API version.
• Inventory integrated services and document important aspects such as their role in the system, what data is exchanged (data flow), and its sensitivity.
• Document all aspects of your API such as authentication, errors, redirects, rate limiting, cross-origin resource sharing (CORS) policy and endpoints, including their parameters, requests, and responses.
• Generate documentation automatically by adopting open standards. Include the documentation build in your CI/CD pipeline.
• Make API documentation available to those authorized to use the API.
• Use external protection measures such as API security firewalls for all exposed versions of your APIs, not just for the current production version.
• Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones.
• When newer versions of APIs include security improvements, perform risk analysis to make the decision of the mitigation actions required for the older version.
3.12. Business Logic Vulnerability
Business logic vulnerabilities occur when APIs are designed with flawed business logic, leading to unintended consequences and potential security issues. In this guide, we will explore the concept of business logic vulnerabilities and how to identify and mitigate them.
Here are two scenarios for business logic vulnerabilities in APIs:
Scenario 1: Flawed Authorization Logic
Background: A company, XYZ Inc., has developed an API to manage user access to sensitive data. The API is designed to allow only administrators to access certain data, but the implementation contains a flaw.
The Flaw: The API checks the user’s role to determine whether they have access to sensitive data. However, the role check is not properly implemented, and any user can access the data by simply changing their role to “admin” in the API request.
Attack: An attacker discovers the flaw and uses it to access sensitive data. They change their role to “admin” in the API request and are able to access the data without authorization.
Impact: The attacker gains unauthorized access to sensitive data, which can lead to data breaches and potential financial losses for the company.
Scenario 2: Inconsistent Data Validation
Background: A company, ABC Inc., has developed an API to process customer orders. The API is designed to validate customer data before processing the order. However, the validation logic contains a flaw.
The Flaw: The API checks for certain data fields, such as customer name and address, but it does not properly validate these fields. For example, it allows customers to enter invalid email addresses.
Attack: An attacker discovers the flaw and uses it to inject malicious data into the API. They enter an invalid email address in the API request, which is not properly validated by the API.
Impact: The attacker is able to inject malicious data into the API, which can lead to system compromise and potential financial losses for the company.
These scenarios illustrate how business logic vulnerabilities can occur in APIs and the potential consequences of such vulnerabilities. By identifying and mitigating these vulnerabilities, API developers and security professionals can ensure the security and integrity of their systems.
How to prevent:
1. Clearly define business rules: Clearly define business rules and ensure that they are properly documented.
2. Implement business rules correctly: Implement business rules correctly and ensure that they are properly tested.
3. Regularly review and update business rules: Regularly review and update business rules to ensure that they remain relevant and secure.
4. Use secure coding practices: Use secure coding practices to ensure that business logic is implemented securely.
5. Conduct regular security testing: Conduct regular security testing to identify and mitigate business logic vulnerabilities.
I hope this content will be used by those interested. My goal in preparing this content is only to help people who have recently started working in the field of API penetration testing and need to get an overview of this field.
Also, I suggest to people who intend to work deeper in this field and gain knowledge to read the wonderful book Hacking APIs written by Corey J. Ball.