Hi everyone! Hope y'all are having an amazing day 🤗
Today, we are going to be talking about API9:2019, or Improper Assets Management. Hope you guys like it and take something useful from it!
🏞️ Getting to Know The Problem
Do you guys remember of the first post of the series? In that blog, we were talking about BOLA, and I mentioned as an example that broken object level authorization might still be found in older API versions if it's not present in newer ones. This might be considered a case of API9:2019 leading to API1:2019, depending on the root cause of the issue. Let me tell you why. 😊
We all know that documentation is important, for several reasons. When it comes to securing APIs, in special, it does help to identify problems such as access control issues and outdated environments.
API9:2019 happens when a company doesn't give the necessary attention to documenting its assets and maintaining properly their inventory, or even when this company doesn't document anything at all 🤭.
As a result, we may have important security fixes not being applied to all the different environments (prod, dev, test...). Also, we may have some environments being "abandoned" with full functionality (including access to the production database) in older versions, which could make all the efforts into securing the other different environments practically null.
📝 Example
Two different instances of the same API are created, with the URLs api.example.com and dev-api.example.com. The second one was made in order to test functions that are still not ready for production, but after a few months, it stopped being used because the company decided that it would be better for the developers to test locally in their own machines. However, because it is relatively cheap to keep an API with no accesses running in a cloud service, it was never shut down.
Later, an endpoint was discovered in the main API, which let any authenticated user to have access to all of the users' PII just by doing the following request:
GET /admin/users/index HTTP/1.1
Host: api.example.com
Authorization: Bearer sup3r_n1c3_t0k3n
After someone discovered the issue and reported it, this issue was fixed in just a few hours. But this endpoint existed since the initial release of the API, and remember that dev-api.example.com is still up and running with no fixes at all.
This means that whenever someone try to do the same request but pointing to the abandoned API instead of the well-maintained one, the PII leakage will still be there! 😲
📚 External materials
As my goal with this series is to just explain what each flaw is, I would like to suggest what I used to learn more about this issue, so you guys get better the details of it:
https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa9-improper-assets-management.md
https://salt.security/blog/api9-2019-improper-assets-management
https://apisecurity.io/encyclopedia/content/owasp/api9-improper-assets-management.htm
Top comments (0)