API9:2019 Improper Assets Management
Introducing breaking changes to a live API with hundreds, thousands, or even millions of active users is (usually) not an option. Releasing a new API version gives a chance to existing users to work on their integrations to migrate to the latest version, without interrupting the service. Nevertheless, maintaining more than one API version or managing different API environments are not easy tasks that often lead to unnecessary API hosts exposure or sensitive data leakage.
What is the issue?
In most cases, the issue is an old APIs left behind running unpatched and with improper security settings. Sometimes, such APIs are connected to production databases, exposing users' personal data.
How does it look like?
To solve some API issues such as the Broken Object-level Authorization and Excessive Data Exposure ones, as well as to add some new API features without breaking existing API clients and integrations, a new version of the “securetodo” API was released: api.securetodo.com/v2/. New mobile applications were released and the API online documentation was updated accordingly.
Now, to get a user's tasks, the mobile application issues the following request:
The "v2" in the request path suggests that there are other versions, at least a "v1", but that endpoint does not exist:
Nevertheless, playing a bit more with the endpoint path, the request gets redirected to a different host:
The vulnerable API version was moved to a different subdomain, but it was left running unpatched, possibly to support old mobile application versions.
Where have we seen this issue lately?
Airtel users' personal data was publicly accessible through an exposed testing API: the issue was solved only when Airtel was notified by an independent security researcher, Ehraz Ahmed. JustDial, somehow, re-introduced an endpoint that was responsible for user data leakage after having retired it. Even more curious, this API was not actively used by JustDial, but it had been left running, providing unprotected access to the production database.
Conclusion
API versioning is one way to keep pushing new features without service interruptions, but managing multiple API versions is not easy. Without a proper retirement plan, for one reason or another, an old API version may be left running unpatched or missing some security features.
To mitigate this risk it is important to have an updated API inventory capable of answering what API environment is running on a specific host, who has access to the API, what version is running, what data is managed by the API, and what the data flow is. Without it, we will keep hearing about data breaches due to exposed (vulnerable) testing/old APIs.