API Protection — What You Need To Know In The New API Economy
Technology is constantly evolving. We’ve seen this in recent years in the way applications are developed (e.g. CI/CD), delivered (e.g. microservices and cloud) and consumed (e.g. more SaaS and mobile devices). If that wasn’t enough we’re also faced with threats from attackers who are also evolving and always seem to be one step ahead of us, the defenders. If we look to those who are watching this space we see that analysts like Gartner say:
“By 2022, API abuses will be the most-frequent attack vector resulting in data breaches for enterprise web applications”
I’ve been a security researcher for many years starting with my time in the Israeli Defense Force (IDF). During my career I’ve worked for a wide range of clients including startups, financial companies and government organizations. I’ve seen hundreds of different vulnerabilities across various environments, applications and APIs. In this article I’ll shed some light on the current state of API protection and changes in the world of applications that are causing the need to look at this problem through a different lens.
It seems like every few weeks there’s another big name company with a high profile breach in the news. Facebook, Panera Bread, T-Mobile, and the list goes on. The most concerning part is that in many cases these companies have sophisticated security practices and yet the security team wasn’t even aware of the breach until months or sometimes years after it happened. They often find out the hard way when user data ends up on the dark web or an attacker asks for a ransom.
One of the main problems I’ve seen is a discrepancy between what is being protected and the security solution being used to provide protection. To explain I’ll give you an example related to my military experience.
Consider What You’re Protecting
As a security researcher in the IDF I was still required to perform my “soldier duties” and once a year I’d get a break from my research and be sent out of the office to guard a random base somewhere in Israel. On one occasion I was sent to guard a military base in the middle of the desert that was nothing more than a single building surrounded by a fence with one door and no windows. A straightforward task with security consisting of me and a few others to protect the entire base. We’d take shifts standing at the single gate and check visitors as they came in. For this base simple perimeter security was enough.
Another time, I was sent to a large military base. This one had various assets; buildings of many sizes, some underground facilities and classified equipment spread across the base. Visitors with different levels of classifications would visit and need to access the various buildings many of which contained different floors with different levels of classified information and access restrictions.
For me, protecting this base was much more of an interesting challenge requiring different layers of security and approaches to provide protection. In order to keep an eye out for suspicious activity and prevent someone from accessing something they shouldn’t, we couldn’t simply rely on a few of us checking bags at the gate. Security here required a much more sophisticated solution including tens of cameras to monitor the assets, a patrol around the base looking for suspicious activity, sensors on each door and window and many other sophisticated solutions. For this base we combined security at the perimeter with layers of security throughout the base to protect the diversity of potential targets.
Traditional web applications are similar to the small military base in the desert where you can rely on traditional security solutions (e.g. WAF, RASP, etc…) to protect them. Those solutions sit at the perimeter and look for known threats to block while letting through all normal looking traffic. The new generation of applications are API-based and in addition to being more complex are also unique like the large base. These require a modern and versatile solution, in addition to the other traditional solutions in your security stack.
The Evolution of Web Applications
Before jumping into the API protection details, let’s understand what’s changed in the world of web applications in recent years to make them more like that big base.
Traditional Web Applications
The previous generation of web applications were multi-page applications. The clients were web browsers with limited processing capabilities and servers would render prepared HTML pages to be sent to the browser. Each HTML page of the website was basically a different page rendered by the server.
Modern Web Applications
Recent years have brought a a huge shift in the way web applications are built and delivered. Clients now including laptops and mobile devices have become faster and more powerful, and browsers are capable of performing increasingly complex tasks. These days a lot of the logic once done on the server has moved to the client and now browsers run complex tasks and perform many actions to render pages dynamically and locally on the client.
Digging Into The Implications
Let’s take a look at the implications of this new model of API-based applications:
- More surface area to defend — traditional applications exposed a small number of HTML pages while modern API-based applications expose lots of APIs, API endpoints and lots of sensitive data. On top of that, modern application environments have many different types of APIs (e.g. mobile application APIs, microservices APIs and B2B APIs noteexposed to other applications and externally to partners)
- Traffic patterns have changed — The traffic between a client and a server looks totally different with API-based applications. In the case of traditional applications, the client sends less data in requests and the server response contains large and complex HTML pages. In modern API-based applications, the client sends more parameters in the request and receives raw data from the server in the response. Both requests and responses are more standardized and have a uniform format (REST/SOAP). If we think about that, the backend server has become more like a data source.
Impact On API Protection
This new API-based application model has a huge impact on security and API protection:
- The bad news — there are new attack vectors that you need to be aware of. API-based applications open the door for new types of attacks that target the logic of the applications through APIs at a very granular level down to each individual endpoint.
- The good news — this model enables new detection approaches since requests and responses with API-based applications are usually standardized and based on a uniform format like REST or SOAP. The standardized format together with artificial intelligence (AI) makes it easier to monitor the traffic and detect suspicious activities.
How To Approach Modern Applications and API Protection
Given the evolution I’ve explained above here’s how we need to be thinking about API protection.
Don’t Rely On Traditional Solutions
Going back to my example: the same way you can’t protect a large military base with a single guard at the gate, you can’t ensure API protection for your modern applications with a simple WAF or any other traditional solution like a RASP, DASP or a vulnerability scanner. Traditional solutions work based on signatures or known patterns and can only protect you from common, known attacks like SQL injection (SQLi), cross-site scripting (XSS), and cross-site request forgery (CSRF). These solutions can’t detect vulnerabilities in the unique logic of your APIs. On top of that, these “old attacks”, once popular, have become less common because of modern application architectures and development best practices. A few examples:
- Cross-Site Request Forgery (CSRF) and some reflected Cross Site Scripting (XSS) attacks can’t be exploited in many modern web applications since they don’t use cookie based authentication.
- SQL injections (SQLi) are becoming less common because application frameworks provide built-in solutions for developers to avoid them.
Attackers haven’t given up and have also evolved to keep up with the times. Your APIs are complex and unique and attackers take advantage of this by looking for vulnerabilities in the unique logic. These are things that can’t be identified by a signature and are too devious to be addressed with good development practices. Your API protection solution must be able to understand the unique API logic at a granular level to identify potential vulnerabilities and stop attacks.
Inventory Your APIs
The breaches we’ve seen in recent years that target the unique logic of APIs are missed by solutions that lack a granular understanding of these APIs. In order to deliver new features and bug fixes quickly, developers often write APIs without thinking too much about structure or beyond basic security principles.
Here are some examples:
Existence of an admin API endpoint under a regular API.
/api/v2/users/export_all_users
Instead of:
/api/v2/admins/export_all_users
Old and temporary APIs that should have been deleted
/api/v2/temp/set_server_key
Internal debugging API that’s exposed to the internet and might expose sensitive data
/api/dev/app_log
The foundation of a good API protection strategy starts with inventorying and documenting your APIs so you can keep on top of changes, find potentially vulnerable points and mark all the endpoints that handle personally identifiable information (PII).
Monitor Your API Activity
One of the most important realities you must face as a company that stores valuable user data (PII, credit cards, etc…) is that at some point, a developer will unknowingly make a mistake which becomes an opportunity for an attacker. Traditional solutions are blind to to these kinds of API attacks. Here’s an example from a stock trading platform I tested with an interesting endpoint:
/api/v2/readTransaction?trans_id=<guid>
This returns details of a specific transaction including PII of the trader. After some research and attempts, I simply removed the trans_id from the request and the server returned a full dump of all of the transactions in the DB. This happened because the developers had assembled a query to retrieve only the details of my transaction based on the GUID sent. When the trans_id was missing, the server returned the entire collection.
Traditional security solutions are simply not granular enough to understand the API logic and can’t detect these types of anomalies, even if it’s something simple like a missing field in the request. Testing or hacking an API is a lengthy trial-and-error process that includes many suspicious anomalies. In order to prevent an attacker from exploiting these unique API vulnerabilities, you must monitor your APIs and detect any abnormal activity.
Summary
Your applications have evolved and so have your threats. As APIs become increasingly prevalent in application environments you can no longer simply rely on traditional solutions to keep you protected from modern attacks. A first step is to inventory APIs in use in your environment so you know what you have to protect. With a granular understanding of your APIs an API protection solution must be able to baseline normal behaviour and look at traffic in real-time to report suspicious activity that could be an indication of potential threats to your APIs. Finally it’s critical that you have the right level of details when suspicious activity is detected so you can quickly stop the threat and work with development teams to close any gaps in the APIs themselves.
Want to learn more about API protection? We have more resources to get you up to speed at the Salt website.
Originally published at salt.security on November 14, 2018.
