“Who can do what?” is still the biggest issue facing APIs.
We are increasingly relying on APIs to power our applications. In this API Security 101 series, let’s discuss the security vulnerabilities that affect APIs, what causes these vulnerabilities, and how to prevent them in your own applications.
You’ve probably heard of the OWASP top ten or the top ten vulnerabilities that threaten web applications. OWASP also periodically selects a list of top ten vulnerabilities that threaten APIs, called the OWASP API top ten. The current API top ten are Broken Object Level Authorization, Broken User Authentication, Excessive Data Exposure, Lack of Resources & Rate Limiting, Broken Function Level Authorization, Mass Assignment, Security Misconfiguration, Injection, Improper Assets Management, and Insufficient Logging & Monitoring. Today, let’s talk about: OWASP API #5, Broken Function Level Authorization.
Before we dive into today’s vulnerability, you’d probably find it helpful to review my post about Broken Object-Level Authorization first. In summary, APIs often expose object identifiers used to access resources. Broken object-level authorization happens when access control is not properly implemented on these endpoints, and attackers can view or operate on resources that they should not have access to.
Broken function-level authorization is a similar issue. Broken function-level authorization is when applications fail to limit sensitive functions to the authorized users. Unlike broken object-level authorization, this flaw refers specifically to when unauthorized users can access sensitive or restricted functions they should not have access to.
For instance, when one user can modify another user’s account or when a regular user can access admin functionality on a site. These issues are caused by missing or misconfigured access controls. They can manifest themselves in many ways, so let’s look at a few examples today.
Example #1: Deleting someone else’s post
Let’s say that an API allows its users to retrieve blog posts by sending a GET request an endpoint like this one:
GET /api/v1.1/user/12358/posts?id=32
This request will cause the API to return post 32 from user 12358. Since all posts on this platform are public, any user can submit this request to access others’ posts. However, since only the users themselves should modify blog posts, only user 12358 can submit POST requests to modify or edit the post.
What if the API does not place the same restrictions on requests sent with the PUT and DELETE HTTP methods? In that case, malicious users might modify or delete other users’ posts by using a different HTTP method. This request deletes another user’s post.
DELETE /api/v1.1/user/12358/posts?id=32
Example #2: Pretending to be admin
The site also allows admins of the platform to modify or delete anyone’s post. So these requests would all succeed if sent from an admin’s account.
DELETE /api/v1.1/user/12358/posts?id=32
POST /api/v1.1/user/12358/posts?id=32
PUT /api/v1.1/user/12358/posts?id=32
But the site determines who is admin with a special header in requests:
Admin: 1
In this case, any malicious user can simply add this header to their requests and gain access to this special admin functionality! Broken functional-level authorization can be caused by both missing access control and the bad implementation of access control.
Example #3: No locks on the door
Finally, the site allows admins to view the site’s statistics via a special API endpoint:
GET /api/v1.1/site/stats/hd216zla
This admin endpoint does not implement any user-based restrictions. The site relies on the fact that the URL endpoints contain a random string at the end to prevent unauthorized users from accessing it. This practice is called “Security through Obscurity,” which means to increase security by withholding knowledge from outsiders.
But security through obscurity is not reliable as the only security mechanism. If an attacker can find out the obscure URL via an information leak, the attacker can access the sensitive functionality hidden behind the endpoint.
What can attackers do?
What can an attacker do with a broken function-level authorization vulnerability? It would depend on the functionality that the attacker can access via the bug. The attacker might be able to impersonate other users, gain access to restricted data, modify others’ accounts, or even become the admin of a site.
The key to preventing broken function-level authorization is to implement granular, strict access control based on the user’s session and ensure that this access control is implemented consistently regardless of a request’s method, header, and URL parameters.
And that’s it for today’s API security lesson. Next time, let’s look at the OWASP API top ten #6, Mass Assignment, and how it allows attackers to compromise the integrity of the application and its data.
What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.
Want to learn more about application security? Take our free OWASP top ten courses here: https://www.shiftleft.io/learn/.
Top comments (0)