Make sure you keep an eye on your APIs
Application programming interfaces have always been important gateways to our applications, but in recent years, they’ve silently become both more prevalent and more central to app functionality. APIs are everywhere and inside of everything we’re using now.
Here’s what I mean: In our workplace, more and more traditional business services are being delivered or amplified by applications. These new applications aren’t the traditional desktop or client-server monoliths, but instead are web applications. What do apps look like now? A patchwork of network-enabled services stitched together over APIs to deliver useful functionality to the user. These applications aren’t managed by human hands, but instead via automation and orchestration frameworks on APIs.
As a result of this proliferation and integration of apps, we have more APIs in our environments, and those APIs have more power—and, therefore, we are more dependent on them. I bring all this up because APIs often go unnoticed by nearly everyone except a handful of individuals working in IT. This often leaves APIs poorly defended and monitored, two factors that make APIs a crucial weak spot in an organization’s cyber defense.
API-related security incidents
F5 Labs has been following API-related security incidents for the past two years. Not only have we noticed them growing in frequency, but they’re also growing in magnitude. Looking at the data from a high-level, we can see that the majority of these incidents can be sorted into three types based on how the affected organizations are using their APIs.
The first, and most prevalent, are API security failures with large platforms. These are organizations like Facebook, Twitter, Salesforce, WordPress, and Valve, which have all had security problems with their API platform integrations. These are high traffic sites offering a wide range of services to customers and partners, and their APIs move enormous amounts of complex data in interactions with thousands of third parties. With so many interactions and opportunities for security to break down, it’s not a surprise when something goes wrong.
Many incidents impacting these large platforms consist of security vulnerabilities publicized by security researchers, not cyber-criminals. Although there is a loss reputation for the victims, there are no tangible financial losses for most. In addition to the technical subversion of apps (hacking), there have been some significant incidents of possible abuse of functionality of APIs—the Cambridge Analytica/Facebook data mining scandal is a good example here.
The second most prevalent type of API security incidents are at mobile application server APIs. Most mobile apps rely on back-end API connections to push or pull data to unpublicized servers. We’re talking about pulling down things like traffic conditions, weather, or social media feeds. Mobile apps, and, to some extent, IoT devices, are sending in things like photos, financial transactions, or GPS data. Attackers will often download and decompile mobile apps to look for hardcoded credentials that supply access to the API. Because these APIs essentially function as the backend database for mobile apps, they are often a treasure trove of valuable user credentials and data.
The third (and increasingly common) type of API security incident stems from misconfigured applications. As I mentioned at the outset, modern applications are woven together from an assortment of services running over APIs. Deploying a large application on a network perimeter or public-facing cloud could mean that some of these interfaces are now Internet exposed. These APIs can be hard to find, as they may listen on non-standard ports or live on buried web paths somewhere on web servers. If not hardened properly, then they become a live login page sitting out on the Internet, available for anyone to discover and try to crack.
API attacks in the wild
As for general API attacks in the wild, we’ve found that only 0.1% of the non-directed attack traffic in 2018 was definitively looking for API vulnerabilities. This makes sense, as most API attacks are targeted to a specific environment and are therefore more customized and difficult to detect than general attack exploits. However, this may change as attackers increasingly discover more general applications with listening APIs placed online.
Our analysis of that undirected API attack-probe traffic showed that 86.7% consisted of scans to identify PHP APIs. We didn’t think this was too much of a surprise, since earlier F5 Labs research found that 81% of all 2018 non-directed web attack traffic targeted PHP sites. Why wouldn’t attackers also include some known PHP APIs in those sweeps?
How do you lock down your APIs?
It helps to understand some basic concepts related to API functionality. Decades ago, I was a computer science student. My fellow students and I were trained in modular programming. Modular programming was a software design methodology that used interchangeable modules within a program to fulfill a specific programming function. These modules were called and coordinated from a simpler program body to fulfill the requirements of the whole application. For example, we had modules for user input, sorting, data storage, transaction processing, and printing. The idea was that you could reuse these modules from program to program and quickly spot bottlenecks or bugs.
You can see how this eventually evolved into object-oriented programming and, now, microservice architecture. When I was a student, our instructors insisted that each of the program modules in our submitted code needed to be robust and self-healing. We were graded down if a module didn’t properly check and verify every single data input passed to it. If unexpected data was passed into the module, then our code was supposed to either reject it with a meaningful error message or fail gracefully.
Even though these modules were used within a single program we had complete control over, we were trained to write code with an expectation of hostile or errored data input, and required to prepare our code against such threats. This is exactly the posture that we need to take with all our API architectures.
These days, code has become more complex—our application landscape has modules running as computer instances in containers woven into a service mesh—but the basic principles for keeping code secure remains the same. Interface points still must be screened, hardened, and protected in transit. If we can’t inspect and scrape what’s coming into our APIs, then we need external security services to do it. This is especially true if the API is connected outside of the local trust context. Some APIs are wide open by design, and don’t require authentication, which necessitates an even greater need for security services.
In the web world, this means verifying and checking HTTP methods, URLs, and access authorizations, and watching for injection payloads. Since a lot of cyber attacker mayhem involves bots, it would be very useful to make use of anti-automation defenses.
Improving API security
A good starting point for improving API security is to develop a technical security standard (sometimes called API security policies) for each API which defines who can do what to which internal services, when they can do it, and how much.
For example, an API that accepts uploaded digital photos should first authenticate the mobile application, then authenticate the user, and after that only allow certain kinds and sizes of uploads, only to that user’s storage, via defined methods. A policy like this makes it much easier to apply security services that inspect and filter, rather than playing whack-a-mole with every new instance of API attack that pops up.
The development and implementation of technical security standards for APIs is especially important when you consider that this is just the beginning. With booming growth of diverse application services, mobile apps, and IoT, I expect to see more API security incidents before we see less. We’re just beginning our journey as an industry into serverless, which entails more API usage and complexity abstraction.
Right now, we are at the early adopter stage of API hacking, with most of the headlines coming from researchers and accidents. Soon the business of cybercrime will move in full force and then we’re really going to have a problem. Proactive development of well-defined security standards as you roll out your APIs will help position industry leaders to avoid the most common forms of API security failures.