OWASP API #9: Improper Assets Management

Published in

strike.sh

4 min readMar 24, 2021

This section

As a reminder, we started with this section more than two months ago 🙌🏻 . Our main purpose, is to share once a week, one of the top cybersecurity attacks that applications are suffering nowadays and help by explaining how you can prevent them from happening.

In each story, we go through ‘Brief explanation’, ‘Is my API vulnerable?’, ‘Attack scenarios’ and ‘How to prevent?’, so by the end you have a comprehensive understanding.

If you missed the previous articles, we encourage you to go have a look. We have already covered:

API #9: Improper Assets Management

When deploying applications and managing infrastructure, a key element and responsibility is to properly manage your assets. As seen in previous posts, there are a lot of attack vectors to which one is vulnerable due to the use of default credentials or not having the latests patch installed.

A different but related topic is assets management. This one has to do with inexistent documentation or old non-production APIs version still being exposed among other things, and has caused companies such as Facebook to be hacked using a beta site.

If you want to avoid this type of problems, you better start documenting and keep your information up to date 💪🏻 .

Brief explanation

As mentioned before, Improper Assets Management has to do with an application not having proper and updated documentation, and outdated versions of the API still being exposed.

Is my API vulnerable?

Your application is vulnerable if:

Old or non-production API versions are exposed, not properly maintained and have access to production data.
There is no documentation, or the existing documentation is not updated.
There is no retirement plan for each API version.
Hosts inventory is missing or outdated.

Example attack scenario

Strike.sh implemented a rate-limiting mechanism that blocks attackers from using brute-force to guess reset password tokens.

This mechanism wasn’t implemented as part of the API code itself, but in a separate component between the client and the official API (vulnerable-api.strike.sh).

A researcher found a beta API host (vulnerable-api.beta.strike.sh) that runs the same API, including the reset password mechanism, but the rate limiting mechanism was not in place.

The researcher was able to reset the password of any user by using a simple brute-force to guess the 6 digits token.

How to prevent?

Keep an up-to-date inventory of all API hosts.
Limit access to anything that should not be public.
Limit access to production data, and segregate access to production and non-production data.
Implement additional external controls, such as API firewalls and WAFs.
Properly retire old versions of APIs or back-port security fixes to them.
Implement strict authentication, redirects, CORS, and so forth.

Conclusion

Although this post was short, I tried to be clear about the implications of lacking good documentation.

I know it seems to obvious and simple, but more often than not I found enterprises really well protected on the outside layer, but just by pealing a bit, they end up being vulnerable because they left an outdated API exposed. Cases such as the one mentioned about Facebook should serve as a notice to everyone thinking this is too easy to fall for.

The solution can take a bit more time because when a release-date is approaching, a lot of times one can only focus on coding, but do not forget to document and check once per quarter that all your exposed endpoints need for sure to be there. Also, if you need to add a patch to a new endpoint, remember to back port it to the previous version.

Thank you for taking the time and reading this week’s story on OWASP API TOP 10. As usual, if you have any doubts or need any help, anyone at Strike will be happy to help you. You can reach out to me here or in LinkedIn!

If you want to see daily news, tips and funny memes (yes, we are into that too :D), be sure to give us a follow there too.

Cheers from Strike :)