How to Find Access Control Issues in APIs
APIs are becoming the Far-Wild-West. What was once old is new again… where basic flaws in user access management expose web applications and APIs to unnecessary risk due to broken access control.
There are many ways to find access control issues in APIs. In this article, I will focus on three specific areas: role-level authorization weaknesses, resource-level access abuse, and field-level authorization abuse.
Where to start?
When you consider the Top 10 OWASP API Security, Broken Function Level Authorization (BFLA) is in the Top 5 vulnerability classes.
Complex access control policies with different hierarchies, groups, and roles, as well as an unclear separation between administrative and regular functions, tend to lead to permission breaches.
By exploiting these issues, you as the attacker are gaining access to resources and/or administrative functions of other users. It also serves as an ideal pivot point for increasing privileges as part of a more impactful chain of destruction.
There are actually three key levels of user access control that you should look at when looking for permission issues. These are at role level, the Resource level, and the field level.
Role-Based Access Control
At the highest level, during the initial reconnaissance of your target, you will have performed a happy path runtime to see how the web application works. You will usually be able to determine different levels of access held by the application. It can be as simple as normal users and administrators. It can also be a complex list of permissions and access rights or specific roles allowing different API users to use the system in entirely different ways.
Security teams usually call this role-based access control (RBAC).
What is RBAC?
Role-Based Access Control (RBAC) is a security model that lets you manage users and their permissions by assigning them specific roles. A role can be defined as a set of permissions allowing the user assigned to that role to perform specific actions. RBAC provides an efficient way to manage users and their permissions, and it makes it easy to add or remove users from a particular role without having to change the permissions assigned to that role.
How to test RBAC
Document each role used by the application
The first thing to do before testing RBAC is to understand the roles used in the application. Document what each user role is allowed to do and, more importantly, what they are NOT allowed to do.
Map roles to permissions
Once you know what each role does, associate it with app permissions and/or features. By doing this, you can better understand the access control design decisions used to protect each API endpoint.
One key aspect you want to research is the difference between administrative access and normal user access. Are there separate API endpoints, or does the access control mechanism handle this through session management with things like an access control token (that’s i.e.: a JSON web token) or maybe via unique parameters?
And if it is possible for an unauthenticated user to make API requests, how does the web service authorization module deny access to endpoints that the user is not authorized to access without to log in ?
By mapping each role to its individual permissions, you begin to get a clear idea of how different users SHOULD and SHOULD NOT be able to use the API.
POINT: Use a spreadsheet. Set individual permissions per column and roles per row. Next, determine which role has which permissions. For example, I like to color-code sensitive perms and quickly cross-reference who has access to what and when. This allows me to quickly determine which user roles I need to attack in my own accounts to get a clear escalation of privileges for a feature I want to abuse or user data I want to access.
Determine the impact of authentication and session management on access
You want to see how APIs identify users. Ask yourself these questions:
- Is it based on query metadata?
- Are the roles defined in an access token claim?
- What about additional headers or parameters?
- How does a given user differ from other users?
- Is it based on a unique identifier?
By digging deeper into the impact of RBAC on things, you can start to think more clearly about broken access control. Examples of attack scenarios such as metadata manipulation and parameter tampering are highlighted and direct access to API endpoints allows us to validate if the principles of least privilege can be defeated.
Resource Level Access Control
Upon discovering your target web application, you will hopefully have identified the parts of the application that require privileged access. From public resources such as the login page to the various authenticated pages within the application itself, you can begin to document unauthorized features that you are denied access to until you pass security checks. specific accesses.
You might even be able to observe missing access controls that allow you to access objects directly from a legitimate request. For example, you may find that there is no authorization check on the login page, but all privileged pages require an authorization token in the request header. Or that to get administrative access to the admin page you need to have more than user roles.
Deepen access to resources
With APIs, there is more to this story. You want to explicitly see if API access allows you to do even more. It’s the key to function level permission broken vulnerabilities. For example, can you change another user’s account information in an account search tool by simply changing the HTTP method from a GET to a PUT? Can you read another user’s account when you’re not supposed to?
As a standard user, can you achieve horizontal elevation of privilege in someone else’s account by simply manipulating insecure direct object references (IDORs), more commonly known as object-level permission broken (BOLA) in the world of API hacking?
Privilege escalation to an administration context
Can you access admin functions just by knowing the admin URL? Or can you access admin rights by changing the state of the internal app?
While you might not have code-level access to the API, you can usually brute force it by tracing every HTTP request. A good attack tool like Burp can do this for you, but so can your browser’s developer tools. I talked about recording this traffic and weaponizing it using HAR captures in a previous article.
Field level access control
How well does the API handle unverified data? The OWASP API Security Top 10 covers an entire class of vulnerabilities across mass assignment which exposes field-level access control issues.
Why is bulk attribution so prevalent in APIs?
In today’s modern web applications, developers sometimes rely on software frameworks to automatically bind HTTP request parameters into program code variables or objects. This can sometimes cause damage.
As an attacker, you can use this methodology to potentially create new settings that the developer never intended, which in turn creates or overwrites new variables or objects in the program code that weren’t intended.
Let me show you how.
How to Exploit Field-Level Access Control Flaws
If an API call blindly relies on user-provided input, it may be possible to elevate privileges simply by modifying the data sent to an appropriate API endpoint. For example, if a field can be tampered with to change API behavior, it might be possible to change how the backend interprets things and expose a function-level permission issue.
Imagine a user record containing the following fields:
- E-mail address
When creating a user in the application, an administrator may be prompted to indicate whether this new user is also an administrator. If so, they check the box and eventually that field is updated.
Now imagine that the developer has added functionality to allow users to update their account password. They probably won’t expose the IsAdmin data in a hidden field, but instead use partial updates, sending a data object with only some of the fields, like maybe the username and new password .
It’s a potential attack vector. Since developers rely on these programming frameworks, you may be able to add the IsAdmin field to the HTTP POST or PUT method for password update and override the IsAdmin field and provide elevation of privilege for the user account.
Permission issues in APIs are a gold mine for us in attack. They can be used to access sensitive data and perform unauthorized actions. In this article, we looked at a few ways to find and exploit access control issues in APIs.
Combining vulnerabilities such as broken object-level permission with broken function-level permission and mass assignment gives us the best chance of achieving vertical privilege escalation nirvana and, hopefully in full control.
If you are looking to hack an API, here are some methods you should keep in mind.
You want to know more ?
Did you find this article helpful? Then be sure to grab my free ultimate guide to API hacking resources. I’ve included many useful resources that I’ve found over the years that have helped me work on my API hacking craft. Hope they can help you too!
The post How to Find Access Control Issues in APIs first appeared on Dana Epp’s blog.
*** This is a syndicated blog from the Dana Epp Blog Security Bloggers Network written by Dana Epp. Read the original post at: https://danaepp.com/how-to-find-access-control-issues-in-apis