Securing APIs: Modern API Security

By Mike Rothman | March 29, 2021

As we started the API Security series, we went through how application architecture evolves and how that’s changing the application attack surface. API Security requires more than traditional application security. Traditional application security tactics like SAST/DAST, WAF, API Gateway, and others are necessary but not sufficient. We need to build on top of the existing structures of application security to protect modern applications. So what does API Security look like? We wouldn’t be analysts if we didn’t think in terms of process and lifecycle. Having practiced security for decades, one of the only truisms which held up over time has been visibility, then control. There are a hundred ways to describe it, like “you can’t manage what you can’t see,” and they are right. Let’s use that prism to look at API security, and that means starting with visibility.

API Visibility

The key to any security visibility effort is to figure out what data is needed and then where you can get it. First, start with the APIs you know about and are documented. That leads you to the OpenAPI specifications, which provide details on the operations the API supports, the API parameters and functions, authentication and authorization requirements, and assorted other information relevant to API usage. With the documented specifications, you can figure out what the API does and identify potential security issues. Although the reality is developers probably haven’t documented all of the APIs in use. They’re busy shipping code, don’t you know? Kidding aside, you can make the case about how building the documentation as the API is defined is the right way to do things, but that may not happen under the stress of a deadline. So we’ll want to look for other places to identify API usage.

  1. API Gateways: We can and will continue to debate the security usefulness of API gateways, but they provide a central point to manage the performance and authentication of existing APIs, routing requests to the appropriate destinations. That means these gateways see API traffic and provide more data about the use of APIs in the environment.
  2. Application Scanning: Though not the most efficient means of discovering APIs, you can scan each application to enumerate available APIs and determine which interfaces are open and potentially exposed.
  3. Passive Monitoring: Finally, you can also look at the traffic on the network to identify and enumerate API usage based on the data you see flying by. A similar technique monitors networks to identify endpoints and even do vulnerability scanning without requiring agents.

Once you’ve found the APIs, you should ensure that data exposed via the APIs do not violate any security policies. Providing a similar function to data leak prevention (DLP), this capability identifies common private data types (SSN, Account IDs, other PII) and looks for proprietary data exposed via the APIs. Detection is the first step. You’ll need to figure out the proper operational motion once sensitive data may be accessible via the API. Who gets a notification, and under what circumstances would you block an API response? Although that’s getting a bit ahead of ourselves. At this point, figuring out potential data exposure remains the priority. Once you have a handle on the APIs in use and any sensitive data accessible via the APIs, we recommend building and maintaining a comprehensive API inventory. Any new or changed API can be compared to the inventory to quickly determine what’s changed and whether it adheres to security policies. Moreover, this is useful to keep track of the API attack surface to ensure adequate protection. Now speaking of protecting APIs…

Securing the APIs

Protection starts with an understanding of the threats that you face. We went through some of those attacks in the last post, but selecting the right protection depends on understanding the threat model. For API security, you protect against two main threats: attacks and misuse. Attacks being what you’d see in the OWASP API Top 10. Misuse is attempting to access sensitive data, impact the API’s availability, or steal credentials and take over accounts. You can search on “OWASP top API attacks” to access some sites with detailed descriptions of the OWASP Top 10 attacks along with mitigation techniques, so we’ll focus on the capabilities you need to protect against all of the attacks.

  1. API Scanning: The first step in protecting the API is to make sure it doesn’t have issues in the definition. Basically, a static API scanning capability that looks for weak authentication and loose parameter, response, or payload definitions, etc. This scanning capability should reflect the organization’s security policies and trigger automatically within the DevOps pipeline during deployment. Analogous to application security scanning, these API scans can be either static (looking at the API code) or dynamic (sending incorrect data to the API to catch incorrect behavior).
  2. Detection and Blocking: If it looks like an attack, it’s probably an attack, and an API security solution needs to be able to detect and block attacks like those enumerated in the OWASP API security list. You’ll also want the API security solution to explicitly enforces the parameters set in the API contract to ensure authorized use.
  3. Anomaly Detection: Shocking as it is, new analytics driving better detection of attacks uses the same approach as network anomaly detection devices that appeared 20 years ago. Improved math/analytics mean better baselines that allow an API security solution to define normal API level down to the user or process level, enabling the detection of obfuscated, slow and subtle attacks and discerning innocent activity from malicious intent. As APIs change, it’s essential to keep the baseline current to maintain this context.

As you consider an API security solution, you’ll get pulled into an age-old question of inline (requiring an agent implemented within each micro-service or container) or out of band (monitoring the infrastructure for API activity). Inline solutions enforce the policies and block attacks directly as they deploy within the application’s data path. On the other hand, you need to install the code within each application or micro-service, and having extra processing within the application can cause latency. The alternative out-of-band approach involves monitoring the traffic to all of the APIs, which has some advantages. These solutions discover hidden (or non-published) APIs since they are monitoring traffic. They also don’t add latency to the application. But they require integrating with other solutions (API gateways, firewalls, etc.) to block attacks. What about the application security defenses you already have? As discussed in the first post, these tools (WAF and API Gateways) aren’t particularly well suited to provide these capabilities. They do well enough on simple attacks identified with signatures. Still, they don’t have application context (gleaned from the contracts and baselining the API traffic) to block sophisticated or subtle API attacks. But finding the issues is one thing, and blocking does stop an attack, but at some point, developers need to make changes to address the security issues, and they need to understand how and why these changes are important. And “because security said so,” isn’t a sustainable position. We’ll wrap up the series by presenting a common-sense approach of educating and assisting the DevOps teams, ensuring applications and data are protected.

3 Comments

A
Adrian Lane 2021-04-20
Identity and access management is always an issue as well; how to provision access and entitlements properly. But what I am finding that concerns me most now is developers are leaving all of the old API version our there. They are not fully deprecated and accessible. And often insecure. You want to add that one to your scans to see what is actually being served on the port.
P
Philippe Leothaud 2021-04-04
As the CTO of a company which has been acting in the API Security ecosystem for the 5 last years, I'd be interested in talking with you about API Security strategies, because I firmly believe that there is no application security without onboarding developers and I see no mention of this in your blog. Also, you say that you can't rely on OpenAPI specification files because developers have no time to write them, and at the same time that you can look to what's in an API Gateway, while you more or less have to have an OpenAPI specification file (or the equivalent) if you want to publish your API to a Gateway. This seems contradictory to me. Another point, how do you "look at the traffic on the network to identify and enumerate API usage based on the data you see flying by" when everything is TLS 1.3? Thanks for your answers, and happy to discuss! Philippe Leothaud
A
Andre Gironda 2021-03-29
Attack Surface Management is an area unknown to API Security initiatives and programs I've seen lately -- and I think it's high order to get them aligned. At least one of the attack surface management platforms I'm working on today has "API Endpoints" as the first clickable item in a list of items. At first glance, I was shocked, "Why would API Endpoint be listed before other services including classic webapps, domains, certificates, networks, services, and the like? Especially when domains and certs seem to seed the other discoveries!" After looking at it more, I discovered that there are actually more API Endpoints than other categoricals! Identifying them and their owners is also more of a chore -- however not impossible, especially with the evidence that the platform provides. Amazingly still are the API Endpoints that were not discovered -- or that were just part of the cloud provider itself. Toolchains such as NetSPI/MicroBurst elicit only a small portion as well. Other services that focus on public buckets and other open-to the public cloud assets are just another "drop in the bucket" for ways to find pathways to cloud assets. My discoveries through these platforms and more have led to further discoveries. I was shocked at how many API endpoints are unique or have a unique component to a specific vendor or open-source project. Fingerprinting these API endpoints is not easy, and may require more than just your average "http.favicon.hash"/"title" etc queries (although strangely, too, these often help at identifying underlying components!). Shockingly so, many Burp Pro and bug bounty toolchains have rose up to discover and document these API endpoints. Today, I feel that the black-box perspective is richer than any other perspective -- not a good situation to be in when actors are zoning in on these endpoints! Commonspeak2, GoldenNuggets, fuzzdb, -- along with gospider and ffuf integrations, are nailing the coffin of the API obscurity into broad daylight. The cloud APIs are too standardized to not be poked at -- and the offensive security tradecraft gets better every day, where the API Security stays stagnant for decades.