コーダーズ・コンカー・セキュリティ OWASP トップ 10 API シリーズ-不適切な資産管理

Unlike most vulnerabilities on the OWASP API top ten, improper assets management does not specifically center around coding flaws. Instead, this vulnerability is more of a human or management problem that allows older APIs to remain in place long after they should have been replaced by newer, more secure versions. It can also occur if APIs that are still in development are exposed to the production environment before they are fully hardened against threats.

This vulnerability is particularly difficult to manage because of the advent of microservices and cloud computing. In that environment, new services may be spun up quickly to meet a temporary need and then forgotten about and never decommissioned. If the older APIs are left connected to the production environment, it can endanger the entire network.

Want to try a gamified challenge on this security bug? Step into our arena: [Start Here]

How do improper assets management flaws affect APIs?

The improper assets management flaw is a product of modern times. Organizations moving at the speed of business can sometimes spin up hundreds or thousands of services and microservices every day. This is often done quickly and without the creation of any accompanying documentation, or any explanation as to what the associated APIs are being used for, how long they will be needed or their criticality. This can quickly generate API sprawl that could become untameable over time, especially if there are no blanket policies in place to define how long APIs can exist.

In that environment, it’s very possible that some APIs will be lost, forgotten about or never decommissioned.

Users with permission to create new services outside of the normal process are also sometimes to blame. For example, a marketing group might create a service to help support an upcoming event like a product launch, and then never take it back down after the event is complete. Someone looking at that service and its associated APIs later might have no idea why they exist, and if there is no documentation, it could remain a mystery. They might not feel comfortable removing those APIs from the production environment or even upgrading them to newer versions because they have no idea how critical they are or what they do.

The vulnerability becomes dangerous because the security of APIs in frameworks improves over time. A researcher might discover a vulnerability, or extra security could be added to stop an increasingly popular type of attack. Older APIs can remain vulnerable to those attacks unless upgraded, so hackers will often search for them or use automated tools to seek them out.

In a real-world example provided by OWASP, a company upgraded its APIs used to search user databases to patch a critical flaw. But they left the old APIs in place by mistake.

An attacker noticed that the location of the new API was something like (api.criticalservice.com/v2). By replacing the URL with (api.criticalservice.com/v1) they were able to instead use the old API with the known vulnerability. This ultimately exposed the personal records of over 100 million users.

Eliminating improper assets management flaws

The only way to eliminate the improper assets management flaw from your environment is to keep a tight inventory of all APIs, their uses and versions. This should start with an inventory of existing APIs, focusing on factors like what environment they should be deployed into like production or development, who should have network access to them, and of course their version.

Once that is complete, you need to implement a process where documentation is automatically added to any new APIs or services that are created. This should include all aspects of the API including rate-limiting, how it handles requests and responses, resource sharing, which endpoints it can connect to, any relevant policies that apply, plus anything else that will be necessary to later audit them. You should also avoid ever using non-production APIs or those from the development environment in production. Consider also adding a time limit to APIs where their continued use must be justified by their owners to prevent automatic decommissioning.

Whenever new versions of active APIs become available, perform a risk assessment to determine if you should upgrade, and how that process should take place to avoid disrupting the production environment. Once you have migrated to the new APIs, remove the old ones completely from the environment.

Doing all of that can help prevent the improper assets management vulnerability from harming your organization, users, or network. Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

‍