--- title: "API Penetration TestingšŸ” Part 2" description: "Reverse engineering APIs with Postman and mitmproxy2swagger, finding excessive data exposure, and scanning for weaknesses. Part two of API testing." canonical_url: "https://amrelsagaei.com/api-penetration-testing-pt2" last_updated: "2025-02-05" --- In our **previous article**, we introduced API hacking, focusing on reverse engineering, scanning for vulnerabilities, and hands-on testing without fluff or distractions. Your response to that guide was overwhelming, and many of you asked for more. So, welcome to part two, where weā€™ll dive even deeper into API reverse engineering, identifying vulnerabilities, and exploiting them. This guide is for those who want to elevate their API testing skills, offering step-by-step explanations and practical demonstrations. If you havenā€™t read part one yet, check it out **here** to build a solid foundation. --- ## **Reverse Engineering an API** When dealing with undocumented APIs, reverse engineering is the key to understanding how they work. This process involves capturing and analyzing requests to map out the API endpoints and their functionality. Here are two methods you can use: ### **1. Building a Collection in Postman** Postman is a powerful tool for collecting, organizing, and testing API requests. Follow these steps to reverse engineer an API: 1. **Launch Postman**: Open Postman and set up a dedicated workspace for your project. For instance, create an **ACE Workspace** to save collections. 2. **Enable the Proxy**: Use the **Capture Requests** feature in Postman. Set the proxy to port `5555` and the target URL to `http://127.0.0.1:8888`. 3. **Use FoxyProxy for Traffic Redirection**: Configure your browser with FoxyProxy to route traffic through Postmanā€™s proxy. Start interacting with the **crAPI**web application (register, login, upload data, etc.). 4. **Capture and Save Requests**: As you interact with the API, Postman captures the requests. Save these requests into a collection, categorizing them by endpoints for efficient testing. ### **2. Automating Documentation with mitmproxy2swagger** To automate the process, mitmproxy2swagger converts captured traffic into a Swagger API specification: 1. **Run mitmweb**: Start mitmweb to capture traffic:```text mitmweb ``` 2. **Set Up Proxy**: Route traffic through mitmproxy using FoxyProxy (`http://127.0.0.1:8080`). 3. **Capture Traffic**: Interact with the API, saving captured requests as a `flows` file. 4. **Generate Swagger File**: Convert the captured traffic into a Swagger API specification:```bash sudo mitmproxy2swagger -i /Downloads/flows -o spec.yml -p http://127.0.0.1:8888 ``` 5. **Edit and Validate**: Edit the generated `spec.yml` file to include any ignored endpoints and validate it using [**Swagger Editor**](https://editor.swagger.io/?utm_source=amrelsagaei.com&utm_medium=referral). 6. **Import into Postman**: Import the Swagger file into Postman for further testing and exploitation. --- ## **Excessive Data Exposure** One common API vulnerability is excessive data exposure, where endpoints return unnecessary or sensitive information. For example: - **Endpoint**: `GET /community/api/v2/community/posts/recent` - **Data Returned**: User IDs, email addresses, and other sensitive details that attackers can exploit. ### **How to Detect and Exploit**: 1. **Review Responses**: Use tools like Postman or Burp Suite to inspect API responses for sensitive data. 2. **Verify Exploitability**: Test if the exposed data can be used to gain unauthorized access or perform further attacks. --- ## **Scanning APIs for Weaknesses** ### **Nikto** Nikto provides a quick overview of server misconfigurations and missing headers: ```bash nikto -h http://127.0.0.1:8888 ``` **Common Findings**: - Missing security headers (`X-Frame-Options`, `X-XSS-Protection`). - Server platform details, such as OpenResty, which may aid attackers in identifying potential vulnerabilities. ### **OWASP ZAP** OWASP ZAP allows for both automated and manual scans to identify deeper issues: 1. **Import API Specification**: Use the Swagger file to define the scope of the scan. 2. **Unauthenticated Scans**: Run active scans to detect public vulnerabilities like Injection or Security Misconfigurations. 3. **Authenticated Scans**: Log in to the app and interact with it while ZAP captures requests. Enable ZAP HUD for live analysis. 4. **Review Results**: Focus on high-risk issues, such as Injection vulnerabilities, found in the results. --- ## **Authentication Attacks** ### **1. Brute-Forcing Passwords** Brute-force attacks test multiple password combinations to crack accounts. Tools like WFuzz simplify this process: ```bash wfuzz -d '{email:user@email.com,password:FUZZ}' \ -H 'Content-Type: application/json' \ -z file,/usr/share/wordlists/rockyou.txt \ -u http://127.0.0.1:8888/identity/api/auth/login ``` **Expected Result**: Successful attempts return a `200 OK` response. ### **2. Password Spraying** Password spraying tests a limited set of passwords across multiple accounts to avoid triggering lockouts. Use Burp Suiteā€™s Intruder with payloads like: ```text Sun@2003! Harverd@2024 ``` --- ## **Authorization Vulnerabilities** ### **1. Broken Object Level Authorization (BOLA)** Test if endpoints allow unauthorized access by manipulating resource IDs: ```text GET /identity/api/v2/vehicle/{resourceID}/location ``` A successful attempt exposes sensitive user data like GPS coordinates. ### **2. Broken Function Level Authorization (BFLA)** Test if users can escalate privileges by modifying endpoint paths: ```text DELETE /identity/api/v2/admin/videos/75 ``` If the request succeeds, it indicates insufficient role validation. --- ## **Improper Asset Management** Older API versions often have weaker security. For example, `/check-otp` has two versions: 1. **Version 3 (**`/v3`**)**: Limits OTP attempts and blocks brute-force attacks. 2. **Version 2 (**`/v2`**)**: Lacks rate-limiting, enabling brute-forcing:```bash wfuzz -d '{otp:FUZZ}' \ -H 'Content-Type: application/json' \ -z file,/usr/share/wordlists/4-digits.txt \ -u http://127.0.0.1:8888/v2/check-otp ``` In this scenario, attackers can brute-force the OTP and reset passwords. --- ## **Conclusion** This second part built on the foundational skills we explored in part one, diving deeper into API security testing techniques. From reverse engineering to detecting vulnerabilities and performing targeted attacks, this guide equips you with actionable methods to enhance your API hacking skills. Stay tuned for the next part, where weā€™ll explore advanced token abuse techniques and bypassing security mechanisms. Keep learning, stay curious, and, as always, stay secure! ## Sitemap See the full [sitemap](/sitemap.md) for all pages.