API-05 Broken Function Level Authorization

Skip to Primary Menu Skip to Utility Menu Skip to Main Content Skip to Footer

Get a Demo

Katie Paxton-Fear

Our final authorization vulnerability, we’ve seen API1 Broken Object Level Authorization and API3 Broken Object Property Level Authorization already but let’s do a quick recap: Broken Object Level Authorization is an access control issues at the object level, so an attacker is able to perform some disallowed action on a resource they do not own, maybe they are able to delete posts even if they are not the author, edit someone else’s order, or read a private post, Broken Property Level Authorization is similar but it’s at the property level, so an attacker is able to see data that should not be exposed to the API or edit data using the API even if there needs to be secondary verification, for example someone being able to change a password directly via the API despite requiring a current password. Broken function authorization is the same idea, but on a function level, usually within a permission hierarchy.

So what does that mean? Simply a user or other lower level account is able to perform the functions of an administrator or other higher authority, a guest user having the function of a regular user. Within SaaS cloud applications this could also include cross-tenancy permission issues as well. The severity of this vulnerability is dependent on what permissions are available.

We once again join Suzy as she builds an administrator control panel for Suzy’s Social, fed up with dealing with emails she wants to consolidate a lot of issues in a single place and hire another person to manage it. She builds administrator functionality based on frequent queries, the ability to report posts to an admin, reset passwords or usernames for accounts that have been stolen, a verification system for brands, government or news organisations so users know a source can be trusted, logging tools and the ability to look up specific users and see their account history. Since she’s building it just for her it’s very easy to hack together and launch with users being none the wiser! Adam, our attacker, notices that the report feature has been added, previously you would @suzy or email suspicious posts. Adam plays around with the feature, reporting a post from Viv, our victim, and observing the new admin API.

Using a suite of API discovery tools he is able to predict many of the endpoints in this API, including the reset username or password facility. Because the API is newer and built quickly he realises that he doesn’t need to be an administrator to use it, he just needs to know what to send. After some trial and error, he cracks the right combination of parameters, query strings and headers to view the API. From here it’s easy, he can edit his account and make himself an admin, change other users usernames or passwords, grant or remove verification for any user and delete his history so Suzy is none the wiser. He treats himself to Viv’s @v username.

You may be wondering why each of these authorization issues are considered separate, because of the large attack surface that can be extremely complex with permission hierarchies, tenancies, custom permissions, a large number of resources with aggregated resources. These features combined with a predictable structure and ease of use make APIs especially prone to access control issues overall. By having these three different types we can more easily describe exactly what element in the API must be fixed.

Speaking of fixes, let’s go over how to fix these vulnerabilities. Usually these are present due to missing access control, either at the route level or the middleware level. For example adding an if statement to ensure the user using an API does have the role Admin and belongs to the same organisation they are trying to edit. Another option is the middleware, checking each request before the response is prepared to ensure the currently logged on user has permission. In simplistic flows it may be more simple to edit the middleware, however in complex permission hierarchies this should be avoided and instead access control should be implemented on each route, as some permissions may give control on every resource rather than every resource in a specific organisation.

To help mitigate these in the meantime, during development define the permission levels, tenants, and super user functionality for each API endpoint, with a conscious decision being made to make the functionality available for each endpoint. Additionally perform regular application security.