The 2022 Year-End API ThreatStatsTM Report provides some very interesting insights into the rise of attacks against API endpoints. They have set themselves the humongous task of diving through a mountain of attacks in order to figure out patterns and trends, and I for one, absolutely applaud them for it.
The main items I’ve found to be of interest are the scale at which attacks against APIs have grown (+192% from 2022), the reiteration of the fact that attackers do not care about the OWASP Top 10 and the focus on Open Source Software (OSS).
Why Open Source is great
To start with the last one, Open Source Software has many great benefits. The first and foremost being the fact that it allows you and everyone else to dive into the code, find bugs, report them and provide bugfixes to the developers.
The downside of this benefit is that it also allows attackers to dive into the code, find bugs, not report them and use them to gain access to your data. Another downside of OSS is that many people are able to find bugs but the average OSS project relies on only one or a few developers to fix it all.
But Open Source has its downfalls
As you can probably imagine this has the potential to become quite a big issue. One of the prime examples for this issue is the Log4Shell vulnerability which we all suffered from in December 2021.
Although the team of developers behind Log4j consisted out of 16 developers, all of them were unpaid volunteers. This means that all of the developers on the project also carry the responsibility of a day job and in their free time need to juggle all responsibilities of a personal life with the responsibilities of responding to bug alerts.
Even though Log4J in and of itself is not that insanely big of a project, its widespread usage in almost all major Java-based programs meant that the impact of this flaw was extreme.
Looking back at Log4J, we can say that at least multiple people could have found the time to find and fix the flaw, but imagine what happens when a lone developer built something genius that was being used by half the world. The chances of that lone developer regularly looking at his/her code of years ago are pretty slim. This means that if you depend on the activity in an open source project, it may take forever before any fix is even attempted.
Now, I am not saying that you should not use Open Source Software, but you should be ready to spend development time to fix issues for that software. Even if it is only to cover your own security.
If I were to be a hacker, I would find the OWASP Top 10 insanely useful
Continuing to work backwards, we get to the OWASP Top 10. Even though it sounds like a good solution to block the OWASP Top 10 (and it is), we also have to understand what the main shortcomings of the OWASP Top 10 are.
The first is maybe obvious: it is a Top 10. This means that it is never a complete list. It is only the list of the most popular attack vectors at a certain point in time. From that perspective, it is the same as traditional AV: since we can’t include all AV signatures, we only include the top-X of virus signatures so you can stop that which is actively going around.
The downside to that approach has always been that you don’t (in case of AV) see the older or less ‘popular’ viruses. For API security this means that if you solely focus on the top 10, you also don’t detect nor block anything but those most-popular 10 attack vectors.
If I were to be a hacker, I would actually find the OWASP Top Ten insanely useful. It would give me the 10 attack vectors that generally don’t stand a chance so I know what I don’t need to try. It simply saves me time in my efforts to breach your API.
How is this the same approach as next-gen AV?
For API security we need to take the same approach as next-gen AV has done. Create strict API specifications and check every API call against that strict API specification. Everything that deviates from the expected inputs should always be blocked. It simply is not an input as the developer has intended.
How is this the same approach as next-gen AV? Next-gen AV doesn’t look at the top-X of most active viruses anymore but looks at every executable and every file to verify whether it is truly safe and it does this by utilizing the power of the cloud. Why don’t we use the power of the cloud for our API security? Continuously adding attack vectors to our API security product and continuously increasing the knowledge of what is coming at us.
The main benefit you have with API security is the API specification. With AV you have to use the power of cloud because you don’t know what executable your users may start tomorrow or which compromised files they may receive. With an API specification we can actually dictate what we want to receive and how that should look like. So do create API specifications and keep improving them to continuously validate your assumptions on what the expected behavior of your API really is.
Containers are one of the very few solutions that I know of that actually work properly using a whitelist
When you’re using containers to publish your APIs the options for security become even bigger. Why stop at looking at the API calls when you can even limit your containers to only running expected processes? Containers are one of the very few solutions that I know of that actually work properly using a whitelist, they have expected behavior that is easily determined! Even if your API is compromised and an attacker (from an API perspective) could start processes within your container, your container security solution can detect that and immediately terminate the running container to prevent further compromise. This combined with building applications using the 12-factor app principles limits your exposure to threats and if threats do appear, this combination limits the impact that those threats (vulnerabilities) have on your data.
Most API security solutions can do so much more!
Now, on to the first item in my list of interesting findings: I believe it makes absolute sense that the attacks against APIs are growing in numbers. More and more of our world is moving to an API-based approach. The monolith is no more (or should be no more) and the applications you run on your devices become more and more an empty shell that utilizes API calls to present you with data. In the end the data is not in the application you use, the data is in the APIs that you communicate with. So why attack a UI if you can directly attack the API?
Make sure you protect your APIs using the best solutions you have (or get one!) and make sure you don’t stop after configuring your solution to block only the top-X threats. Most API security solutions can do so much more than that!
