Attackers are like modern-day cartographers. The cartographers of old weren’t necessarily sailing the coastline of New England, drawing a map as they sailed. Instead, they layed back in their crib in Genoa and talked to people who did the sailing. They picked brains, plied sailors with strong drink, gathered information, and sifted through contradictory claims to build their mental model of Cape Cod and Boston Harbour. And then they drew the map. Today’s cyberattackers work in a similar fashion. But the map isn’t New England, it’s your API, and the reason they’re drawing that map isn’t to explore it, it’s to attack it, and to steal your data. You could say they’re crafting treasure maps.
X Marks the Spot
What does that treasure map look like? We spend our days in the ThreatX SOC trying to stay one step ahead of the attackers, and we’ve learned quite a bit about their tactics and techniques. We’re sharing some of the most common ways we see attackers trying to compromise APIs.
Searching for Open-Source Intelligence
It starts with looking for open-source intelligence on your API. Attackers will hunt for any kind of available information about a target. Old developer notes, or even one of your developer’s Stack Overflow posts could contain paths to endpoints that shouldn’t be exposed to the public. Info leak anyone? In addition, there are also a lot of tools available that can identify the kind of tech stacks you have. For example, a tool like Wappalyzer could tell an attacker what kind of database you’re using, and they’ll use that information to inform an attack, trying SQL injection in a field that normally wouldn’t accept that.
Get all the details on how attackers are abusing APIs and the best practices in API protection in The Definitive Guide to API Attack Protection.
Watching the API in Action
Ideally, attackers want the ability to see what is being sent to an API endpoint. They want to understand the structure of the requests being made and the schema that is being used. But that’s not always available, so that’s why they will lean heavily on documentation, or try to access the web application that’s interacting with that API endpoint.
There are tools like Burp Suite and Zap that attackers use to see the interaction between a web application and an API. These tools are a proxy between your web application and API; they’re essentially acting as a man-in-the-middle. It makes it really convenient for attackers to profile your API and start documenting and collecting information about what normal traffic looks like. These tools also provide the ability to make changes to the traffic that is flowing through them.
Fuzzing is another important method for attackers to use when assessing how an endpoint interacts with anomalous data. Fuzzing tools allow an attacker to inject invalid inputs into a system in an automated way to reveal potential software defects and vulnerabilities. Burp and Zap have fuzzers built into them; dirb, dirbuster, ferroxbuster are other popular options. These fuzzers can aid an attacker in identifying common endpoints or methods leveraged by an API.
For APIs specifically, attackers will use Postman in conjunction with proxy tools. This tool allows attackers to craft payloads and is commonly used by attackers to repeatedly interact with an API.
Testing the Possibilities
Attackers will push the boundaries of your endpoints and try all kinds of ways to compromise their intended behavior. Maybe you think your endpoint will only accept strings, but they’re going to try integers, they’re going to try a Boolean, they’re going to try all different kinds of input types. And maybe your endpoint does accept strings, but it only accepts 20 characters, or you hope it only accepts 20 characters, but they’ll try 200 characters. Or 2X10^6 characters. Attackers are very creative; they come up with unique inputs that your engineers most likely never thought of.
They’ll also try to figure out what they have access to. Maybe you only wrote this API thinking that a machine would interact with it, and so it’s only going to glean information. But an attacker will try to edit or delete the information or make it appear differently under certain circumstances. Ultimately, when we’re protecting endpoints, we have to be right all the time, but the attackers only have to be right once!
Not If, When
It’s not if attackers are going to target your APIs, but when. They will target anything on Layer 7. Enumeration, fuzzing, reverse engineering, injections, broken authentication, all of these tactics will come together in some form of an attack, whether it be large scale or low and slow. So the more you know about what you have and what you’re trying to protect, the better prepared you’ll be.
Watch the recording of our Live Q&A on API Attack Surface Awareness and Management.
How to Prevent API Attacks
Being prepared is ultimately about security in depth. Like treasure maps with trap doors and labrynthine puzzles, layers of security are needed to protect against modern attacks. Below are some suggestions based on our experience.
From the engineering side:
- Give security a seat at the table when designing new software. Having a security professional in the room during design, even during sprint grooming where you’re talking about an approach to a problem, is going to make the development team more security aware. Security professionals can think like an attacker and can also work with engineering teams to build security into the product.
- Watch for spikes in error codes. These runtime events indicate either bad code, or bad actors.
- Question all anomalous activity. Changes in traffic patterns can indicate that there is a new area of interest or your former strategy of “security by obscurity” is now failing.
- Ensure input sterilization. Every single input you have, every key value pair in API needs to have sterilized input. If possible, create an allowlist of acceptable and expected input. Friends don’t let friends strcopy.
- Obfuscate your endpoints – Don’t name your auth endpoint “end_user_authorization.” If you do that, you might as well hang out a sign that says “hack me here.”
- Keep track of your API versioning strategy. If you deprecate an endpoint, make damn sure those old artifacts aren’t still deployed on some container somewhere, even in your dev environment. Those become prime targets for attackers.
- Be thoughtful about privileged access models. Understand which roles are intended to perform particular actions and ensure that any deviation from that intention is both blocked and logged for later audit.
From the security side:
- Work closely with developers and take part in the development process to provide a unique attacker-centric perspective.
- Create abuse cases to validate attack mitigation techniques.
- Track, manage, and update an inventory of all APIs and their versions
- Regularly test your application using static, dynamic, and manual techniques.
- Deploy with perimeter protection in place.
To learn more about API attack protection, check out our new guide, A Security Practitioner’s Introduction to API Protection.
