The Consequences of Poor Authentication and Authorization Practices in APIs

In part one of this series, we discussed why Application Programming Interfaces (APIs) supported by microservices require a new way of authenticating and authorizing users.

And while it’s always good to learn the security principles and techniques used to protect your application, it’s also critical to understand the potential impact when the code is vulnerable.

In this post, we’ll cover examples of real-world API vulnerabilities. Look through the examples to understand how attackers could breach your defenses and what to look for when designing and building your authentication (authN) and authorization (authZ) system.

Why Aren’t These Vulnerabilities Found Sooner?

Before we begin our breakdown, let’s tackle the obvious question. Automated testing tools are becoming increasingly sophisticated. Why can’t they find authN and authZ vulnerabilities while the developers are writing code or in a testing environment?

Security testing tools like Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) aren’t effective at finding authentication and authorization vulnerabilities. SAST tools scan source code with no knowledge of the architecture or business logic. DAST tools are great at finding vulnerabilities against running applications, but complicated business logic escapes them.

Interactive Application Security Testing (IAST) is probably the best option for discovering these types of vulnerabilities, but it’s not 100%.

As you’ll see when we discuss concrete examples, authentication and authorization systems are complex with many steps. There is frequent back-and-forth communication between the client and API. There are password recovery systems, login implementation, and service-to-service authentication. All of these moving parts lead to unexpected interactions. Testing tools can’t predict what unique set of steps might lead to a compromise. Let’s take a closer look at some examples.

Shopify: Broken Object Level Authorization in Kit App

You can find this vulnerability’s details on Hacktivity. A hacker named Sandie found the flaw via bug bounty, and he was awarded $1,000 for his efforts. This vulnerability is a textbook Broken Object Level Authorization (BOLA) flaw, which happens to be No. 1 on the OWASP API Top 10 list.

BOLA occurs when an attacker changes an ID parameter in a Uniform Resource Identifier (URI) to view a resource they are not authorized to view. Imagine a medical application where you can change a parameter and see someone else’s medical records.

The vulnerability found in Shopify’s Kit app isn’t quite as catastrophic as exposing medical records, but it illustrates how BOLA can slip into any API.

The Kit app is an automation tool Shopify store owners can use to manage marketing tasks like Facebook ads, emails, and integrated apps. The vulnerability allowed an attacker to obtain the authorization token for a high-permission user of Kit using a low-permission account.

The attack begins with a URI requesting an authorization token for Shopify Ping to talk to Kit.

/api/v1/arro_token?access_token=███████&myshopify_domain=alwayzhack.myshopify.com&id=42668326968

This endpoint will generate a token for the given account ID. The API expected that the currently logged-in user would send their ID to the API, and all is well. Unfortunately, the hacker discovered that passing a high-privileged user’s ID into this endpoint will return an authorization token for that user. The attacker could use this token to send requests to Kit as an administrator and view the previous messages.

This type of vulnerability could be hazardous for any API. It allows an attacker to impersonate an admin-level user and perform any actions they desire.

How would you prevent this attack? The issue is the “id” parameter used to identify the user requesting the token. The API assumed that the ID passed in was the ID of the corresponding user. Instead, it should’ve checked every request to ensure that the current user ID matched the ID given and that the ID passed in has authorization to operate the app or function.

Shopify: Anyone Can Become a Collaborator Without the Store Manager’s Permission

The appearance of another Shopify vulnerability isn’t an indictment of their security. It’s a compliment. They’ve embraced thorough testing to find these issues and disclose them so others can learn from these mistakes.

This Shopify bug, which we've done a breach analysis on, exemplifies another vulnerability on the API Top 10, Broken Function Level Authorization (BFLA). BFLA occurs when non-privileged users can perform certain privileged operations.

Shopify has a partner program where service providers help store owners with various tasks, such as store design, build, or marketing. Typically, the collaborator enters the store URL they want to be associated with, and the store owner approves the request. Upon approval, the browser sends a request to a specific endpoint: /admin/settings/account/approve/<id>.</id>

A security researcher named Uzsunny discovered that this endpoint didn’t check if the API call came from a store manager. Any user could call the endpoint and approve the request, opening the door for anyone to give themselves administrative access to any store on the platform.

BFLA flaws are sneaky and can be challenging to find. They usually exist due to a missing authorization check in the endpoint code or as the result of assumptions that come back to bite you.

Facebook: Password Recovery API Allows You to Take Over Any Account

Facebook had an authentication bug, which we've also done a breach analysis on. This bug allowed anyone to take over an account. It was an exploit of the password recovery functionality.

First, a user enters their email address to start the password recovery process. Facebook then sends a six-digit code to the user via text message. The user enters the code and resets their password. The browser sends a POST request to the “facebook.com/recover/as/code” endpoint with the code.

This endpoint implements rate limiting to prevent attackers from brute-forcing the reset code. However, several endpoints under the beta.facebook.com and mbasic.facebook.com domains didn’t have rate limiting enabled.

An attacker could take over any account using this process:

1. Enter the victim’s email address on the password recovery page
2. Brute force the six-digit reset code by sending requests to the beta.facebook.com and mbasic.facebook.com endpoints

Even though this vulnerability was primarily due to forgotten endpoints containing old code, it illustrates that authentication processes, especially “forgot password” functionality, are prime targets for attackers. Any hole in your authentication processes could lead to a catastrophic breach.

How You Can Prevent Authentication and Authorization Flaws

These examples of real-world exploits show what can happen when companies don’t do authentication and authorization correctly. As long as humans are writing code, mistakes can creep in. But there are steps you can take to build secure APIs and reduce risk.

In our next post, we’ll outline the tools, technologies, and processes to do authentication and authorization right. Be sure to subscribe to our blog so you can get the next installment.

‍

About the Author

Justin Boyer is a former software engineer and application security specialist turned technology writer and a regular contributor to The Inside Trace.