Mastering API Penetration Testing: A Comprehensive Guide for Security Pentesters

Understanding API Penetration Testing:

API penetration testing involves assessing the security of application programming interfaces (APIs) by simulating attacks to identify vulnerabilities. It’s crucial due to the increasing reliance on APIs in modern applications, ensuring the protection of sensitive data and preventing unauthorized access.

Please note that this methodology is not a recommended or standard approach; it’s based on my personal experience gained from bug bounty programs and extensive penetration testing of API endpoints, combined with my own collection of methodologies.

Source: https://dzone.com/articles/security-best-practices-for-rest-apis

Tools for API Penetration Testing:

• Burp Suite: For intercepting and analyzing HTTP/S traffic to test for vulnerabilities like injection attacks and security misconfigurations.
• SQLmap: Specifically used to detect and exploit SQL injection vulnerabilities in APIs.
• Commix: A tool focused on detecting and exploiting command injection vulnerabilities.
• Bettercap: To perform network monitoring, sniffing, and performing Man-in-the-Middle (MITM) attacks, session hijacking and especially SSL stripping.

Bonus: Bettercap setup:

• Installation: Install BetterCAP on your system by following the installation instructions provided on the official BetterCAP GitHub repository or website.
• Preparation: Make sure you have two network interfaces, one for connecting to the internet and the other for creating a Wi-Fi access point or LAN. Configure your network interfaces accordingly.
• Start BetterCAP: Launch BetterCAP with the appropriate privileges (e.g., as root or with sudo).

SSL Stripping with BetterCAP:
1. Start Sniffing: Begin by running BetterCAP in sniffing mode. Use the command to start sniffing on the network interface:

sudo bettercap -iface <interface_name> - sniffer

2. Enable HTTP Proxy Module: Enable the HTTP Proxy module in BetterCAP, which allows you to intercept and modify HTTP traffic:

set http.proxy.sslstrip true

3. Start Proxy: Start the HTTP proxy server to intercept and manipulate HTTP traffic:

set http.proxy.address <your_IP>:<port_number>
http.proxy on

4. Enable HTTPS Downgrade: Enable SSL stripping to downgrade HTTPS connections to HTTP:

set net.sniffer.output none
set net.sniffer.verbose false
set arp.spoof.internal true
arp.spoof on

5. Launch MITM Attack: Initiate a Man-in-the-Middle (MITM) attack on the target by ARP spoofing:

arp.spoof on

6. Capture and Analyze: As BetterCAP intercepts traffic, it will capture and display HTTP requests and responses. Analyze the captured data to identify any HTTPS traffic that has been downgraded to HTTP.

Please note that this is a simplified example and may not cover all configurations or scenarios.

The use of such techniques must be lawful and performed only with explicit permission to test your own systems or with proper authorization in authorized testing environments. Unauthorized interception of traffic or any malicious intent is illegal and unethical. Always comply with local laws and ethical guidelines when conducting security testing.

Day Zero Checklist:

• Credentials and Access: Ensure access to all endpoints, APIs, and functionalities using valid credentials or tokens.
• Functionality Testing: Verify that all functionalities work as expected to ensure the in-scope coverage.

High-Priority Checklist:

1. Authentication & Authorization:

• Test effectiveness of authentication mechanisms.
• Check authorization checks to prevent unauthorized access.

Specific test cases for AuthN:

• Brute Force Attack: Attempt to perform brute force attacks on login endpoints by trying numerous combinations of usernames and passwords. Analyze the API’s response to repeated login attempts, verifying if it implements account lockouts or rate-limiting mechanisms after multiple failed login attempts.
• Weak Password Testing: Test the API to see if it allows weak or easily guessable passwords during account creation or password reset processes. Ensure that strong password policies are enforced.
• Credential Stuffing: Check for credential stuffing attacks by using known breached credentials against the API endpoints. Verify if the API detects and prevents the usage of compromised credentials.
• Token Manipulation: Assess how authentication tokens or session cookies are generated, transmitted, and validated. Attempt token manipulation techniques to modify, replay, or forge tokens to gain unauthorized access.
• Multi-factor Authentication (MFA): Verify the implementation and effectiveness of MFA mechanisms if present. Attempt to bypass or manipulate MFA controls to access the system without providing the second factor.

Specific test cases for AuthZ:

• Privilege Escalation: Test if authenticated users can access resources or perform actions beyond their authorized permissions. Attempt to modify request parameters or tamper with tokens to escalate privileges.
• Role-Based Access Control (RBAC) Testing: Verify if the API properly enforces RBAC policies. Attempt to access resources or endpoints that are restricted to specific roles or groups.
• Vertical and Horizontal Escalation: Test for vertical privilege escalation by attempting to perform actions restricted to higher-privileged roles. Also, verify against horizontal privilege escalation, ensuring users cannot access another user’s data.
• Forced Browsing/IDOR (Insecure Direct Object References): Probe for IDOR vulnerabilities by manipulating URLs or parameters to access unauthorized resources or user data.
  State-Based Authorization: Assess how the API handles authorization based on user states (e.g., logged-in, logged-out, suspended). Test if access is correctly granted or denied based on user states and transitions.

2. Input Validation & Sanitization:

• Probe for SQL injection, NoSQL injection, and other injection attacks.
• Verify how API handles user inputs to prevent data manipulation.

Specific test cases for Input validations:

• Boundary Testing: Test boundary conditions by sending requests with different parameters to ensure that the API properly enforces limits and restrictions. For instance, exceeding pagination limits or accessing endpoints with invalid parameters.
• Invalid values: Test for invalid parameters or values in the API requests to ensure that the server does not accept invalid values, and more importantly, does not throw an internal server (500s) error exposing sensitive information directly.

SQL Injection Test Cases:

• SQL Injection (Basic): Attempt to inject SQL queries into API parameters, such as username or search fields. Use payloads like ‘ OR 1=1 — to check for basic SQL injection vulnerabilities and observe API responses.
• SQL Injection (Blind): Test for blind SQL injection by sending requests that cause delays or trigger conditional responses. Look for differences in response times or error messages to confirm injection.

Time-based blind SQL Injection Payload:
For databases that support time delay functions, such as MySQL’s SLEEP() or PostgreSQL’s pg_sleep(), you can use time-based payloads to cause intentional delays in the API’s response. Here’s an example payload:

MySQL:

' OR (SELECT 1 FROM (SELECT SLEEP(5)) as test) - -

PostgreSQL:

‘ OR (SELECT PG_SLEEP(5)) — -

Conditional Blind SQL Injection Payload:
Conditional blind SQL injection involves crafting payloads that cause conditional changes in the API’s responses based on true or false conditions.

For instance:

OR CASE WHEN (YOUR_CONDITION_HERE) THEN 1 ELSE 0 END - -

Replace (YOUR_CONDITION_HERE) with a condition that you expect to be true, such as 1=1 for true or 1=2 for false.

By observing changes in the API responses, such as different error messages or behavior variations (e.g., a different response code), you can determine if the injected condition has been evaluated as true or false, indicating a potential vulnerability to blind SQL injection.

NoSQL Injection Test Cases:

• NoSQL Injection (Basic): Send requests with NoSQL injection payloads to parameters expecting NoSQL database queries. Use variations of {“$ne”: null} or {“$gt”: “”} to test for inequality or regex-based NoSQL injection vulnerabilities.
• NoSQL Injection (Boolean-Based): Probe for Boolean-based injection by sending requests with true/false conditions to infer database responses.

In NoSQL databases, Boolean-based injection involves sending requests with true/false conditions to infer database responses. Here’s an example of a Boolean-based NoSQL injection payload:

Consider an API endpoint that performs authentication using a NoSQL database, where the query might look for a user based on a username and password:

POST /api/login
Content-Type: application/json
{
 "username": "attacker",
 "password": {"$regex": "^a.*", "$options": "i"}
}

To perform Boolean-based injection, an attacker can manipulate the password field to create a condition that always evaluates to true or false. For instance:

True Condition:

{
 "username": "attacker",
 "password": {"$regex": "^a.*", "$options": "i", "$gt": ""}
}

The condition $gt: “” tries to match a password greater than an empty string, which is always true, indicating that the query should match all passwords.

False Condition:

{
 "username": "attacker",
 "password": {"$regex": "^a.*", "$options": "i", "$gt": "zzzzzzzzzzzzzzzzzzzzz"}
}
Here, the condition $gt: “zzzzzzzzzzzzzzzzzzzzz” tries to match a password greater than a long string, which is unlikely, resulting in a false condition, indicating that the query should not match any passwords.

Here, the condition $gt: “zzzzzzzzzzzzzzzzzzzzz” tries to match a password greater than a long string, which is unlikely, resulting in a false condition, indicating that the query should not match any passwords.

Command Injection Test Cases:

• OS Command Injection: Send requests with OS command injection payloads to input fields expecting system commands. Use variations like ;ls or && dir to test for command injection vulnerabilities.
• File Path Traversal: Probe for path traversal by manipulating file paths within requests. Use ../ to navigate outside the intended directory structure and access unauthorized files.

XML External Entity (XXE) Test Cases:

• XXE Basic Payload: Inject XML payloads containing external entities. Use the below payload to test for XXE vulnerabilities and observe if sensitive data is exposed.

• Blind XXE: Send requests containing entities that cause delays or conditional responses to determine XXE vulnerabilities without direct feedback.

3. Error Handling & Information Leakage:

• Evaluate error messages to prevent information disclosure.
• Ensure proper error handling to enhance resilience against attacks.

Specific test cases:

• Invalid Inputs: Submit requests with intentionally malformed or invalid data and observe the error messages returned by the API. Check if error messages reveal specific details about the API’s internal workings or sensitive information such as stack traces, database errors, or file paths.

Example:
Submitting a request with a malformed JSON object or incorrect data types in parameters to see if error messages provide details about the error source.

• Boundary Value Testing: Send requests with values near or beyond the acceptable boundaries to test how the API handles edge cases. Check if error messages reveal unexpected behavior or expose system information.

Example:
Submitting a request with maximum character length input fields or with values that exceed the defined limits to see if error messages disclose handling of such cases.

• Stack Traces and Debug Information:
  Exception Handling: Test the API with inputs that trigger exceptions or errors. Examine API responses to determine if detailed stack traces or debugging information is exposed to the client.

Example:
Sending requests that intentionally trigger a server-side error (e.g., division by zero) and analyzing the response for stack trace details.

• Security Misconfiguration Testing:
  Default Error Pages: Access non-existing endpoints or directories to check if the API serves default error pages that could reveal server information or version details.

Example:
Accessing a non-existent endpoint (e.g., /api/nonexistent) and observing the response headers and body for server information.

4. Session Management:
Assess session handling mechanisms for vulnerabilities like session fixation or hijacking.
Verify secure session timeout settings.

1. Session Token Change:

• Initial Session Token: Log in to the application and note the initial session ID or token.
  Re-use of Session Token: Log out and attempt to reuse the same session token (previously captured). Verify if the server allows the use of an old session ID after logout.

2. Session Hijacking:

• Session Prediction:
  Predictable Session IDs: Check for predictable or sequential session IDs. Login multiple times and compare session IDs to identify patterns or sequential IDs.
  Shared Sessions: Log in from multiple devices or browsers using the same credentials. Verify if the sessions can be used interchangeably between devices.

3. Session Token Transmission:

• Check Transmission Security: Analyze how session tokens are transmitted between the client and server. Ensure that session tokens are transmitted securely via HTTPS and not exposed in URLs or HTTP parameters.

4. Session Timeout Settings:

• Idle Session Duration: Log in and keep the session idle for an extended period. Verify if the session times out after the specified idle time and requires re-authentication.
• Activity-Based Timeout: Perform regular actions within the application and monitor if the session expires according to the activity-based timeout setting.

General Session Management Best Practices:

• Session Regeneration on Authentication: Check if the application generates a new session ID upon successful authentication or sensitive actions like changing passwords.
• Logout Effectiveness: Log out of the application and verify if the session is effectively invalidated, preventing further access without re-authentication.
• Session Revocation: Change the password while an active session is ongoing and verify if it invalidates the existing sessions, ensuring the old session token becomes unusable.
• Cookie Flags: Check for attributes such as ‘HttpOnly,’ ‘Secure,’ and ‘SameSite’ flags in session cookies to ensure they are set appropriately.

5. Data Privacy & Protection:

• Review data encryption during transmission (HTTPS) and at rest.
• Ensure sensitive data is adequately protected.

Specific test cases:

• SSL/TLS Stripping: Attempt to intercept traffic or force downgrade attacks to see if the application is vulnerable to SSL/TLS stripping, where the attacker forces HTTP instead of HTTPS. Bettercap is a nice tool to automate this testing.
• Data Handling Policies: Assess how the application handles sensitive data (credit card numbers, passwords). Verify if it encrypts this information before storing or transmitting it, following data protection policies.

6. XSS & CSRF Protection:

• Detect and mitigate XSS vulnerabilities in API responses.
• Verify safeguards against CSRF attacks to prevent unauthorized actions.

Specific test cases:

• Reflected XSS: Inject script payloads into input fields or parameters to execute arbitrary JavaScript in the user’s browser. Use <script>alert(‘XSS’)</script> or <img src=x onerror=alert(1)> payloads to test for reflected XSS.
• Stored XSS: Inject scripts into API parameters expecting user-generated content. Store malicious scripts in user profiles, comments, or other fields to execute when accessed by other users.
• DOM-Based XSS: Test for DOM-based XSS by injecting payloads that manipulate the DOM. Use JavaScript code like document.cookie = ‘attacker_cookie’ to check if client-side scripts execute in the expected context.

I personally love using different payloads from SecLists.

GitHub - danielmiessler/SecLists: SecLists is the security tester's companion. It's a collection of…

CSRF Test Cases:
1. CSRF Token Implementation:

• Token Verification: Send a request with a valid session but an incorrect or missing CSRF token and verify if the API rejects the request due to the mismatched CSRF token.

2. Anti-CSRF Tokens:

• CSRF Token Regeneration: Check if CSRF tokens are regenerated after each authenticated session or action. Ensure that tokens are unique per session and action. Especially for POST requests.

3. Origin Header Validation:

• Origin Header Check: Test if the API validates the ‘Origin’ or ‘Referer’ headers to verify the request’s source, preventing requests from unauthorized origins.

4. State-Changing Requests:

• Protection Against State-Changing Requests: Attempt to perform state-changing actions (e.g., POST, PUT, DELETE) via forged requests and verify if the API prevents these actions without valid CSRF tokens.

5. Double Submit Cookies Method:

• Cookie Verification: Verify if the API checks if the CSRF token is present and matches the cookie sent along with the request.

7. Business Logic Vulnerabilities:
Assess the API’s business logic to prevent unauthorized access or data exposure.
Ensure proper validation of input data.

Specific test cases:
1. Business Logic Abuse:

• Business Logic Flaws: Analyze the API’s core business logic to identify logical flaws or discrepancies that might allow unauthorized actions or data exposure.
• Manipulate State Changes: Attempt to manipulate states or transactional processes to create inconsistencies or unexpected outcomes in the API’s behavior.

2. Forced Browsing and Enumeration: Test if it’s possible to enumerate resources or access functionalities by guessing or iterating through identifiers or enumeration of objects.

8. Rate Limiting & Throttling:

• Check for adequate controls against DoS attacks — try calling the API using Intruder ‘null’ payloads for 1K times minimum.
• Verify the effectiveness of rate limiting mechanisms.

9. Host Header Injections:
Specific test cases:

• Host Header Manipulation: Test if the application is vulnerable to host header manipulation leading to potential attacks.

Steps:
1. Send a request to the application endpoint with a modified or manipulated ‘Host’ header, containing a different domain or IP address than the original target.
2. Analyze the application’s behavior; observe if it responds differently or redirects to the manipulated domain.

• Bypassing Access Controls: Test if the application is vulnerable to host header manipulation leading to potential attacks.

Steps:
1. Send requests with altered ‘Host’ headers to access restricted resources, APIs, or admin panels that are intended for internal use only.
2. Analyze the responses to determine if the application improperly grants access based on the manipulated ‘Host’ header value.
3. Verify if the altered ‘Host’ header leads to unintended privilege escalation or exposes sensitive information.

10. Server-Side Request Forgery:
Specific test cases:

• Basic SSRF: Identify if the application allows an attacker to make arbitrary requests to internal or external resources.

Steps:
1. Submit requests to different endpoints within the application that accept URLs or file paths as input parameters.
2. Manipulate these inputs to include URLs pointing to internal network resources (such as ‘http://localhost' or ‘file:///’) or external resources.
3. Analyze the application’s behavior to identify any successful retrieval or access to unintended resources based on the input provided.

• Out-of-Band SSRF: Check if the application facilitates outbound connections triggering an out-of-band network interaction.

Steps:
1. Inject a payload into an input field that initiates an external network interaction (e.g., HTTP requests to an attacker-controlled server).
2. Monitor the attacker-controlled server logs for any incoming connections or interactions initiated by the application.

11. Insecure Deserialization:
Specific test cases:

• Modification of Serialized Data: Verify if the application performs proper validation and sanitization of deserialized data.

Steps:
1. Identify an endpoint or functionality that accepts serialized data (e.g., JSON, XML, etc.).
2. Inject manipulated or malicious serialized data containing unexpected or malicious content (e.g., modified object properties, crafted payloads).
3. Analyze the application’s behavior upon deserialization, looking for any unexpected or dangerous outcomes, such as object instantiation, code execution, or unexpected method calls.d connections triggering an out-of-band network interaction.

• Exploiting Code Execution: Check if the application’s insecure deserialization allows code execution.

Steps:
1. Craft a serialized payload that, upon deserialization, triggers code execution (e.g., PHP object injection, Java deserialization vulnerability).
2. Send the malicious payload to the application.
3. Monitor the application’s behavior for any signs of unintended code execution, such as system commands being executed, unauthorized access to resources, or unexpected behavior.

• Deserialization of Untrusted Data: Determine if the application blindly deserializes data from untrusted sources.

Steps:
1. Intercept or modify serialized data in transit between client and server (e.g., intercepting API requests/responses).
2. Tamper with the serialized data by injecting unexpected or malicious content.
3. Observe the application’s response upon deserialization to check for vulnerabilities, such as object manipulation, data tampering, or unexpected behaviors caused by the manipulated data.

Advanced Testing Techniques:

• Additional Attack Vectors: Explore more attack vectors related toserver-side request forgery (SSRF), insecure deserialization, or serverless-specific vulnerabilities if applicable to your testing scenarios.
• API Injection Attacks: Test for SQL injection, command injection, and parameter tampering to exploit vulnerabilities.
• Unexplored HTTP Methods: Check for unhandled HTTP methods that might expose vulnerabilities.
• Parameter Tampering: Evaluate hidden fields and inputs to ensure their values cannot be manipulated.
• Path Traversal: Test for path traversal vulnerabilities where an attacker manipulates file paths to access directories or files they shouldn’t have access to. By manipulating the input parameters, attackers might gain unauthorized access to sensitive files, leading to data breaches.
• API Gateways and Third-Party Services: Expand on security considerations when APIs interact with external services or utilize API gateways. Assessing security controls in these interactions is crucial.
• Container Security: If APIs are deployed within containers (Docker, Kubernetes), consider including tests related to container security, such as container breakouts or vulnerabilities in container images.

Low-Risk but Recommended Practices:
Please remember that while these low-risk practices might not pose immediate severe threats, implementing them strengthens the overall security posture of the API and minimizes potential attack vectors. Adjustments and additional considerations might be needed based on specific API architectures and security requirements.

• Insecure Hashing: Examine how the API handles password storage and hashing. Insecure hashing algorithms include — MD2, MD4, MD5, SHA-1.
• HttpOnly Cookies: Verify that session cookies are set with the HttpOnly flag, preventing client-side scripts from accessing them. This reduces the risk of cross-site scripting (XSS) attacks.
• SameSite Attribute: Ensure that cookies are set with the SameSite attribute, which restricts cookies from being sent in cross-origin requests, minimizing the risk of CSRF attacks.
• Secure Flag: Validate that sensitive cookies, especially those involved in authentication, are set with the Secure flag, ensuring they are transmitted over secure HTTPS connections only, preventing interception over unencrypted channels.

For simplification, let us see what directives are comparatively safe or unsafe to be used. But note that, determining the security posture based on these directives completely depends upon the context in which it is used.

Strict-Transport-Security (HSTS):
Safe Attributes:

• max-age: Specifies the time in seconds for which the HSTS policy is enforced.
• includeSubDomains: Instructs browsers to apply the HSTS policy to all subdomains.

Unsafe Attributes:
• preload: Indicates that the domain should be included in browser preload lists. Although it’s not inherently unsafe, adding a site to the preload list requires careful consideration and validation, as changes can’t be easily undone.

Content-Security-Policy (CSP):
Safe Directives:
• default-src: Sets default sources for various content types.
• script-src: Specifies valid sources for JavaScript files.
• style-src: Specifies valid sources for stylesheets.
• img-src: Specifies valid sources for images.
• font-src: Specifies valid sources for fonts.

Unsafe Directives:
• unsafe-inline: Allows inline script or style execution, increasing the risk of XSS attacks.
• unsafe-eval: Permits the execution of JavaScript code from strings, which poses a significant security risk for XSS attacks.

X-Content-Type-Options:
Safe Attribute: (To have this header is itself considered secure)
• nosniff: Instructs the browser not to sniff MIME types and to adhere strictly to the declared content type.

X-XSRF Headers (Cross-Site Request Forgery Protection):
Safe Headers: (To have this header is itself considered secure)
• X-XSRF-TOKEN: Typically used to store anti-CSRF tokens.
• X-Requested-With: May be used by frameworks to detect AJAX requests.

Thanks for joining me on this journey through API pentesting! I’ve poured my heart into crafting a personalized checklist, aiming to cover all bases. Your feedback means the world! Let’s dive in together and brainstorm more test cases or new elements to add. Together, we can support developers in creating secure systems. Cheers to a community-driven effort for more secure development practices!
P.S> Let me know if you are interested in this checklist, I can create a GitHub repo with this checklist with an easy to use excel sheet for you all :)