Anders Askasen is the Director of Technical Marketing EMEA at Okta. He has worked on security and identity for almost 20 years. In this article, he discusses Zombie APIs.
An overwhelming majority of all the traffic on the internet today is API driven. API-driven traffic is nearly 83%, which means that normal HTTP traffic is a fraction. Everything we’re doing, from Netflix to Myro, is back-ended by APIs, API calls, and API traffic. Most companies have an API strategy. They’re trying to build out APIs as a product or using the APIs to provide services to partners, internally or externally.
So, as a hacker, if you want, you have a massive attack vector to exploit these APIs. You have an easy way to access information. You can potentially extract personally identifiable data and put companies at a massive risk.
Zombie APIs
A zombie API is an API that an organization has sanctioned, built, launched, and, over time, forgotten. But it’s still lingering around. It’s still there. And what is dangerous is that the partners are still using earlier versions because it is still available. That’s where the problem is. We have these lurking zombies in our application infrastructure, where the potential of leveraging these APIs as a hacker is massive. Such APIs open up and expose your enterprise to attackers that can leverage these holes.
But these APIs cannot be just killed off because we have posted them publicly. We have partners and customers using them; maybe we even use them internally. And even if we do have our stuff together, they might still be lingering around in a UAT environment. So, just removing them may have an impact on our business. There may be associated costs. That is why when we’re implementing and posting APIs, we need to consider this and not as an afterthought. So, when we have APIs that we post publicly, we need to ensure that we have a funeral date; we will kill them off. And we’re going to have a proper burial. That is very, very important.
Many tools are available to look for Zombie APIs. You must look for them regularly, and once you find them, you must act on them immediately.
API breaches
API developers are stressed; they have tight deadlines, so they sometimes cut corners, which can lead to problems in the code. Regular penetration tests do not always discover all these problems. You need deep penetration tests, which cannot always be automated because, at times, you have to think like a hacker to check if any loopholes are open.
Vulnerabilities listed by OWASP
Every year OWASP provides a list of vulnerabilities. Some of them are –
- Organizations implementing their own identity layer often implement incorrect authentication mechanisms where attackers can compromise authentication tokens or exploit flaws that allow an attacker to assume other users’ identities temporarily or permanently.
- Complex access control mechanisms and authorizations with different hierarchies, groups, and roles between administrative and regular functions tend to lead to flaws that hackers can exploit.
So, these are the typical two problems you’ll find when it comes to APIs or any public application.
Things to look for
There are three types of things here that you could potentially look at –
- Spikes in user database connections may signal that more users are logging in than usual.
- Spikes in queries to post-authentication services like balance checking, profile details, or any other service that might be of value to a fraudster.
- Stress on backend databases, like a retailer’s inventory database, or spikes in errors.
You need to ensure that you have the right monitoring tools in place to be able to detect these. Because if you don’t have the right monitoring when problems happen, you want to be able to detect it and do something about it.
Conclusion
To summarize, most traffic on the internet is today API driven. Zombie APIs are APIs that you forgot about, and they’re still lingering and lurking around. To ensure this does not happen, you need to have monitoring tools to catch and manage these APIs. Ensure that your governance model includes a funeral date and make sure that we put that guy to rest that API to rest. As part of the governance process, we need to communicate with all our partners and customers to ensure they don’t use the APIs.
