OWASP API Security Top 10 API9:2019 Improper Assets Management with Example


In the previous blog, we learn about the OWASP API Security Top 10 API8:2019 Injection with an example. In this blog, we will learn about the OWASP API Security Top 10 API9:2019 Improper Assets Management, its impact, an example, and remediation.


What is Improper Assets Management?


When the outdated version of APIs is still being utilized in the production environment, technical documents have not been kept current, or staging/under-development APIs are exposed. It will pose a risk to the organization as the old version of API or staging/under-development APIs is typically unpatched, insecure, or utilizes outdated authentication or authorization mechanisms. 

Example 1:


Suppose there is a web application that contains the number of APIs with v1 (example.com/api/v1) after sometimes developers change the design of the application to enhance the performance and security of the application and launch a new version of APIs that is, v2 (example.com/api/v2), and push it to production. Still, they didn't stop the service of version 1 of API, so when the attacker replaces the v2 with v1, the attacker can access the old version of APIs that are still unpatched and vulnerable. 

Example 2:


Suppose there is a shopping web application that uses APIs (www.shoppingapp.com/api/v1) in the backend, and there is a security feature in the shopping web application that restrict the users from using the same coupon code multiple time. This feature is implemented using a third-party component. During reconnaissance, an attacker found the Staging URL (www.stag.shoppingapp.com/api/v1) of the shopping web application that also points to the production database. The attacker could use the same coupon code multiple times in a single order to reduce the bill amount because, in the backend, the third-party component that restricts the users from using the same coupon code multiple times is disabled. 


How to check if the API is vulnerable to Improper Assets Management


  • If APIs documentation is not up-to-date
  • If the old versions of APIs are still used in production
  • If staging/under-development APIs are exposed
  • If Integrated third-party or first-party security services are missing or outdated


Demo:


For the demo, I am using one POST-based API endpoint that will perform the login by taking the username and pin in the HTTP request.



As we can see in the above image, there are 2 Headers present in response to implementing rate limiting.

X-RateLimit-Limit: 5
X-RateLimit-Remaining: 4

When I sent the same request again, then X-RateLimit-Remaining became 3 



After sending the same request five-time, the application responded to 500 internal server error.



In the URI, the API version is set to v2 when I replace the v2 to v1 and send the request, then the server response is 200 OK, and there are no rate-limiting headers in the response, which means that the old and insecure version of the API is still in production.



Since there are no rate-limiting headers, we can perform a brute-force attack. To do so, I send the request to the intruder and select the pin value as the payload position. 



In the payloads section, I select payload type as Numbers, from 0000 to 9999 with step 1, set min integer length and max integer length as 4, and Start the attack.



After the brute force attack is completed, I found that there is one API response whose length is different from other response.



When I check the API response for the same request, I found the flag.



Remediation


  • Document all API endpoints, their functionality, usage, and Keep them up-to-date
  • Document all the integrated services (first-party or third-party), including permissions 
  • Document all the security 
  • Draft a compressive document that covers the authentication mechanism and process, errors, Rate limiting method, CORS implementation, and all endpoints, including their parameters, request, and responses 
  • Generate API documentation as part of the CI/CD process
  • Use external security mechanisms like Web Applications and API Protection (WAAP)
  • Restrict access to the non-production environment by using a Private network
  • Disable old version API endpoints when the new version is used in production  

Sahil Gupta

Application Security | DevSecOps | Secure SDLC | Penetration Tester (Web and API) | CEHv10 | IBM Certified Cybersecurity Analyst Professional

Previous Post Next Post

Contact Form