Featuring Matt Tesauro, Noname Security’s DevOps Distinguished Engineer, and project lead for OWASP Appsec Pipeline project, and OWASP’s DefectDojo.
More than 80% of Internet traffic is API initiated. As API calls continue to escalate exponentially, it’s not surprising that API security incidents are on the rise. Just like any other type of commercial code under development, APIs should be part of the secure development lifecycle, but that’s not usually the case, says Matt Tesauro, Noname Security’s DevOps distinguished engineer. In this interview, he discusses how APIs are used, their pervasiveness in commercial applications, and how to implement API development as part of a holistic SDLC process.
Q: What are APIs commonly used for?
There are three major categories. In business-to-consumer (B2C), the APIs sit behind mobile or web apps. When I buy coffee at my favorite coffee chain using my mobile phone, a lot of the integrations and customizations are done through APIs, which allow the heavy lifting to happen at the back end.
The other side is business-to-business (B2B). Say my business wants to run a loyalty card, but I don’t want to run that pointed loyalty system. I can have a third party run that for me, but I need to be able to tell the third party that John is my customer and Sally just bought something, so she gets ten points. That almost always happens over APIs.
The third big area of use for APIs is cloud computing. All the cloud resources are API-driven by design.
Q: What are some of the common risks or vulnerabilities caused by or through APIs?
APIs have great benefits for companies because a single API can hold business functionality for a mobile version, web version, and maybe even the client version without having to rewrite a lot of code. But we haven’t really thought through the security aspect of this.
Of the OWASP API Top Ten vulnerabilities, a couple of them really stand out. One is Broken Object Level Authorization (BOLA). I have a token that identifies me to an API, but instead of using the ID for my profile page, it will use someone else’s ID and get that other person’s information sent back to my client. While convenient for developers, the APIs don’t validate when my token is asking for someone else’s information.
The other ones that happen frequently are called Excessive Data Exposure and Mass Assignment. To create APIs quickly, developers will take in a JSON object and write it directly to a database. What if I add admin=true to my profile page, and I submit that? The API automatically writes that up to a database, and suddenly I’m an admin.
Pro Tip: For more on OWASP’s top ten API vulnerabilities, click here.
Q: How can developers prevent their APIs from introducing vulnerabilities?
APIs seem to be off the radar in the application security domain. A lot of this is due to a lack of automated tooling. When I ran product security at Rackspace, I had to use low-level tools to test, and even with twelve people on our AppSec team, we couldn’t keep up.
So, in the planning phase, the big thing is to understand how you are going to do authentication and authorization. A lot of companies will centralize this function at the API gateway, which I think is a generally good model to use. Say I have a C#, Java, and Python version of authorization; why not get that centralized through an API gateway?
Authentication is an important area that developers should focus on as well. A friend of mine at GitHub once told me that every time they tightened their controls on the website, they saw a spike in attackers logging into the API. The web has geolocation of IPs, browser profiling, and MFA, but there aren’t the same controls for APIs. So, every time they tightened their authentication on the web, the attackers moved next door and started poking their APIs. They finally took their authentication login out of their APIs and moved them fully to the web.
Data conversion is another area to focus on. Watch out for those libraries that take in JSON and turn it into a database save, or vice versa. Those ‘automagical’ conversions of data in/data out allow data to leak inadvertently. For example, maybe Sally wrote the original implementation, and she’s working at a different company now, so Jim adds something innocently, not realizing that a database column is also going to be put out in an API recall. A good model is to have separate data objects, one for your internal application to use and a second one to map to the API responses. Data will not go out as JSON unless specifically added by a developer.
Q: Should APIs be scanned and tested before release?
Absolutely. This used to be a fully manual process when I worked at Rackspace, but today’s tools can be wired into your CI/CD. One of those tests could be, let’s run a dynamic pre-production assessment and include it in the developer’s workflow with an automated feedback loop.
Pro Tip: Check out this GrammaTech Blog on using SAST to Detect API Usage Anomalies. GrammaTech has also produced an educational document on Open-Source API Usage Error Detection.
