Coders Conquer Security OWASP Top 10 API Series - Improper Assets Management

Published Dec 22, 2020
by Matias Madou, Ph.D.
cASE sTUDY

Coders Conquer Security OWASP Top 10 API Series - Improper Assets Management

Published Dec 22, 2020
by Matias Madou, Ph.D.
View Resource
View Resource

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.

View Resource
View Resource

Author

Matias Madou, Ph.D.

Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

Want more?

Dive into onto our latest secure coding insights on the blog.

Our extensive resource library aims to empower the human approach to secure coding upskilling.

View Blog
Want more?

Get the latest research on developer-driven security

Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.

Resource Hub

Coders Conquer Security OWASP Top 10 API Series - Improper Assets Management

Published Dec 22, 2020
By Matias Madou, Ph.D.

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.

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.