> For the complete documentation index, see [llms.txt](https://ahmed-tarek.gitbook.io/security-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ahmed-tarek.gitbook.io/security-notes/notes/api-pen/improper-assets-management.md).
# Improper Assets Management
#### Discovery
* **Explore API Documentation**: Review API documentation to pinpoint parameters tied to account properties, crucial functions, and admin actions. This can reveal areas of potential risk in asset management.
* **Intercept Requests and Responses**: Use tools like Burp Suite to intercept API traffic. Inspect parameters and responses to spot any that may need further testing.
* **Parameter Guessing and Fuzzing**: Experiment with parameters that accept user input, focusing on those that could affect account variables or allow manipulation during account creation and editing.
#### Testing Procedure
Follow these steps to test for Improper Asset Management vulnerabilities:
**1. Baseline Versioning Information**
* Understand the API’s versioning by examining paths, headers, and parameters. Track supported production versions (e.g., `v1`, `v2`, `v3`).
* In **Postman**, create a test to detect status code 200, verifying successful responses for baseline comparison.
**2. Run an Unauthenticated Baseline Scan**
* Conduct an unauthenticated scan on the API collection using Postman’s Collection Runner.
* Save responses to establish a baseline and for further analysis.
**3. Review and Analyze**
* Examine the unauthenticated scan results to understand how the API responds across different versioning.
* Look for anomalies in behavior or access control.
**4. Collection Version Replacement**
* Use the "Find and Replace" function to convert version-specific details into variables within Postman for flexibility in testing multiple versions (e.g., `v1`, `v2`, `v3`).
**5. Set Environment Variables**
* Add a Postman variable called `"ver"` and set its initial value to `v1`.
* Update this variable to test other versions, such as `mobile`, `internal`, `test`, `uat`, and observe responses.
**6. Collection Runner with Version Variables**
* Run the collection with different version values, checking for inconsistencies in response.
* Note any unexpected responses for non-existent paths, particularly if they result in 200 OK statuses, which may signal asset management issues.
**7. Identify and Investigate Anomalies**
* Review differences in responses, especially in critical actions like password resets, across versions.
* Investigate specific endpoints for potential weaknesses, such as unlimited password reset attempts or open OTP validation paths
Impact Analysis and Brute Force Testing
1. **Impact Assessment**: Gauge the potential impact, such as whether an API version allows excessive attempts for password resets without restriction.
2. **Brute Force with WFuzz**: Use WFuzz to test parameters like OTP validation.
```bash
wfuzz -d '{"email":"hapihacker@email.com", "otp":"FUZZ","password":"NewPassword1"}' \
-H 'Content-Type: application/json' \
-z file,/usr/share/wordlists/SecLists-master/Fuzzing/4-digits-0000-9999.txt \
-u http://crapi.apisec.ai/identity/api/auth/v2/check-otp --hc 500
```
* Look for unauthorized access indicators in successful brute force responses.
**Brute Force Review**
* Analyze brute force outcomes for any unauthorized access capabilities. Confirm if the vulnerability could allow unapproved actions.
Authenticated User Testing
* Run the tests again as an authenticated user to ensure consistency and rule out unexpected behavior in protected API versions.