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.
