API9:2019 Improper Assets Management - OWASP API Security Top 10

Overview

This is an overview of the API9:2019 Improper Assets Management vulnerability as part of the OWASP API Security Top 10. It highlights the impact, vulnerability, and attack vectors associated with this security weakness.

Description

API9:2019 Improper Assets Management is a vulnerability that occurs when old API versions are left unpatched and lack proper documentation. This can lead to the exposure of sensitive data and compromise the security of the server. Attackers can exploit this vulnerability by gaining access to old API versions connected to the same database. This vulnerability is prevalent due to outdated documentation, lack of assets inventory, and the presence of unnecessarily exposed API hosts. It is essential to have a clear understanding of the API environment, network access, API versions, and data flow to prevent this vulnerability.

How to Prevent ?

To prevent API9:2019 Improper Assets Management, it is recommended to inventory all API hosts and document important aspects of each one, including the API environment and network access. It is also crucial to inventory integrated services and document their role in the system and data flow. Furthermore, documenting all aspects of the API, such as authentication, errors, redirects, and rate limiting, can help prevent this vulnerability. Generating documentation automatically and making it available to authorized users is essential. Using external protection measures like API security firewalls for all exposed versions of APIs is recommended. Additionally, avoiding the use of production data with non-production API deployments and performing risk analysis for security improvements in newer API versions are important preventive measures.

Example Attack Scenarios:

• Scenario #1:  In this scenario, a local search service left an old, unprotected API version running and connected to the user database. An attacker, while targeting a newer application, discovered the API address and used it to gain access to the old API version, exposing the personal identifiable information (PII) of millions of users.

• Scenario #2:  In this scenario, a social network implemented a rate-limiting mechanism to prevent brute-force attacks on reset password tokens. However, a beta API host running the same API without the rate-limiting mechanism was discovered. A researcher exploited this vulnerability to reset the passwords of users through brute force guessing of the 6-digit token.