Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Do you follow the same procedures to secure a web application as you do an API? Is there a difference between the two?
We’ve spoken about API security quite a bit in the past few months because we believe that there are critical differences between API security and traditional web application security. A lack of understanding of those differences is dangerous.
Let’s look at the differences between the two and why you should treat API security differently from application security in general.
What is API security?
API security is the practice of defending web APIs against attacks. Building APIs, typically with microservices as the foundation, has become a growing trend. Many mobile applications and websites send and retrieve data using APIs, even if the end user is unaware of this fact.
APIs are different from traditional web applications, and those differences can lead to critical security issues.
What Makes APIs Different From Traditional Web Applications?
I’ll answer that question with a picture, then proceed to “drop the mic.”
(Picking the mic back up.)
The above picture illustrates why APIs are fundamentally different from traditional web applications. What was once one request to one server has become dozens or hundreds of requests to dozens or hundreds of microservices.
Previously, the work was relatively easy; defend one large application. Now, you have to protect hundreds of small web applications and the data they access. Authentication and authorization don’t look the same. The built-in session management of your favorite framework has gone out the window. Each microservice is its own little kingdom.
In addition, you now have to know where all of these API endpoints reside, what version they’re running, and how to scale them when demand increases.
Finally, changes to the development and deployment environment cause changes in how malicious actors attack applications. Are you familiar with the new ways attackers target APIs?
What Are the Most Significant Threats Against APIs?
The OWASP API Top 10 project outlines 10 dangerous risks with APIs. (See this post for the breakdown.)
Instead, let’s look at the big themes the API Top 10 brings to the forefront. Then we’ll discuss some specific breaches that illustrate what happens when APIs are vulnerable.
Authentication and Authorization Win Top Prize
Okay, maybe “Most Likely To Get You Hacked” isn’t much of an award, but authentication and authorization are the most prolific and dangerous API security flaws.
Authentication and authorization in APIs feel like a new world for many developers. A development framework doesn’t manage a session, but instead, applications pass JSON Web Tokens (JWT) around with claims attached. In a nutshell, every microservice must verify the caller’s identity and permissions before performing any work on their behalf.
As the number of APIs grows, it’s more likely that developers will miss some authorization checks, and a data breach is waiting to leap out and strike when you least expect it.
API Endpoints Are Everywhere
I remember taking my two-year-old daughter to Disney’s Magic Kingdom during spring break. I had to slip a kiddie leash on her to make sure she didn’t disappear in the crowd. It was challenging to keep track of only one child in that vast mass of people.
An explosion of microservices fills your infrastructure with a crowd of endpoints, and kid leashes don’t seem to fit Docker containers very well. It’s easy for APIs to disappear.
Unfortunately, these “shadow APIs,” whether spun up by a developer for testing purposes or just an old version left out in the wild, can become a point of attack. They may not be secure, and if you don’t know they’re still publicly exposed, someone could be attacking it without your knowledge.
Examples of Real API Vulnerabilities
Let’s illustrate the differences between API and web app security by looking at real vulnerabilities.
Shopify “Collaborator” Vulnerability
Security researcher Uzsunny found a critical flaw in the Shopify “collaborator” functionality that allowed an attacker to assign themselves the “collaborator” role on any store. This feature unlocks all sorts of administrative functionality.
It turns out that the API endpoint that handles this collaborator business logic didn’t verify that the request to add a collaborator to a store came from the store manager. Therefore, anyone could call that endpoint with the right arguments and get admin rights to any store on the Shopify platform.
Check out our detailed post on how this vulnerability works and why it’d be hard to detect.
Facebook Authentication Bypass Using Shadow APIs
Obscurity isn’t security, and determined attackers will find forgotten API hosts. The AppSecure cybersecurity research team found a way to gain access to any Facebook account via a couple of API endpoints Facebook forgot existed. The AppSecure team received a $15,000 bug bounty.
Although found in 2016, this bug illustrates a kind of vulnerability prevalent in API architectures. This bug was subtle but demonstrated how the smallest crack could let an attacker run amok.
The bug existed in Facebook’s password recovery logic. When a user requested to recover their account because of a forgotten password, they received a random six-digit code via text message. They enter the code in the browser, which sends an API call with the code.
Facebook placed rate-limiting on the endpoint to protect against brute-force attacks. The API blocked client requests after 10 failed attempts. However, API endpoints existed on other hosts, and Facebook’s engineers didn’t realize it. An attacker could send payloads to “beta.facebook.com” and “mbasic.beta.facebook.com” and brute force the recovery code. These endpoints didn’t have the ten try limit.
Uber API BOLA Vulnerability
Broken Object Level Authorization (BOLA) is number one on the API Top 10 list. Uber’s API had this vulnerability. Thankfully, it was discovered by security researchers before malicious actors did damage (as far as we know). But it illustrates well how dangerous BOLA can be.
The vulnerability leaked sensitive information, including an authentication token that could be used to perform a full account takeover.
The vulnerability appears when a new driver joins the Uber platform. The browser sends the “userUuid” to the API endpoint, and the API returns data about the driver used to populate the client.
Unfortunately, the API endpoint didn’t check if the calling client had the authorization to view its returned details. An attacker could add another “userUuid” and get a sizable JSON object with the other user’s account details, including first and last name, email address, and user identifiers.
This vulnerability illustrates that revealing too much information is dangerous for any API (Excessive Data Exposure is number three on the Top 10). Also, inadequate authorization checks can lead to account takeover with minimal effort.
Check out our detailed post to learn more about this vulnerability.
The Future of API Security
Application security technologies such as Web Application Firewall, Next Generation Web Application Firewall, and Runtime Application Self-Protection don’t typically find the kinds of vulnerabilities we’ve discussed. These attacks present as ordinary traffic, so many defenses let them through.
The future of API security lies with business logic. Application security tools have to understand the application’s context and business logic to know that non-managers shouldn’t be adding collaborators to a store or that a client shouldn’t access that user ID’s information.
Traceable AI uses machine learning to learn the application’s business logic, so these types of attacks are found and stopped. See Traceable AI in action and see what the future of API security looks like.
