The industry’s first “State of API Security” report is here

Download report

API5:2019 Broken Function Level Authorization

Michael Isbitski
Michael Isbitski
Feb 18, 2021

Description

Authorization flaws are often the result of improperly implemented or misconfigured authorization. Implementing adequate authorization mechanisms is a complex task, since modern applications can contain many types of roles, groups, and user hierarchy such as sub-users and users with more than one role. This is further complicated with distributed application architectures and cloud-native design. Broken function level authorization (BFLA) shares some similarity to BOLA in this regard, though the target with BFLA is API functions as opposed to objects that APIs interact with as in the case of BOLA. Attackers will attempt to exploit both vulnerabilities when targeting APIs in order to escalate privileges horizontally or vertically. 

Attackers discover these flaws in APIs since API calls are structured and predictable, even in REST designs. This can be done in the absence of API documentation or schema definitions by reverse engineering client-side code and intercepting application traffic. Some API endpoints might also be exposed to regular, non-privileged users making them easier for attackers to discover.

Attackers can exploit these flaws by sending legitimate API requests to an API endpoint that they should not have access to or by intercepting and manipulating API requests originating from client applications. As an example, an attacker could change an HTTP method from GET to PUT. Alternatively, the attacker might also alter a query parameter or message body variable such as changing the string “users” to "admins" in an API request.

Potential Impact

Attackers exploiting broken function level authorization vulnerabilities can gain access to unauthorized resources, take over another user’s account, create/delete accounts, or escalate privileges to gain administrative access.

Example

In the example above, the attacker has changed the method from POST. to DELETE allowing them to delete the account associated with user_id=exampleId_100. Access to the DELETE method should have been restricted to users with administrative access but was allowed due to an inadequate authorization policy.

Real World Example

Facebook reveals another privacy breach, this time involving developers

https://www.zdnet.com/article/facebook-reveals-another-data-breach-this-time-involving-developers/ 

In 2019, Facebook disclosed that roughly 100 application partners may have been able to gain unauthorized access to data through the Facebook Groups API, which provides an interface between Facebook and 3rd party applications. 

In April 2018, Facebook restricted 3rd party applications using the Groups API to only access information such as the group’s name, the number of users, and the content of posts. For an app to access additional information such as name and profile picture in connection with group activity, group members had to opt-in. Facebook found that after April 2018 some apps had retained access through the Groups API to group member information, like names and profile pictures in connection with group activity.

Why Existing Tools Fail to Protect You

Traditional security controls like WAFs and API gateways lack context of API activity and therefore do not know that the attacker in the example above should not be able to send a DELETE method. This API call would be seen as legitimate and would pass through these security controls. WAFs and API gateways  sometimes support explicit, statically defined message filters, often referred to as a positive security approach. However, these approaches can inhibit or break business functionality, and most organizations find them difficult to operationalize at scale. Restricting HTTP methods is also an easier task than restricting API parameters and values, the latter of which requires deeper subject matter expertise on the design of the API.

The activity in the Facebook example above would be missed by WAFs and API gateways for the same reason. These security controls would not know that the 3rd party applications should no longer have access to the deprecated or restricted API functions. Tuning the controls would have required appropriate knowledge transfer between development, operations, and security teams to implement an appropriate static filter in the appropriate proxy within the overall enterprise architecture. 

How to Protect Broken Function Level Authorization Vulnerabilities

API security solutions must be able to continuously baseline typical HTTP access patterns per API endpoint and per user. With this baseline, API security solutions can identify calls with unexpected parameters or HTTP methods sent to specific API endpoints such as in the DELETE example above. It is critical that the solution is capable of baselining continuously, as APIs may go through a high rate of change as a result of modern development and release practices. API security solutions must be able to identify and prevent attackers or unauthorized users from accessing administrative level capabilities or unauthorized functionality as in the Facebook example above.

Previous posts:

API1:2019 Broken Object Level Authorization

API2:2019 Broken User Authentication

API3:2019 Excessive Data Exposure

API4:2019 Lack of Resources & Rate Limiting

Next posts:

API6:2019 Mass Assignment

API7:2019 Security Misconfiguration

API8:2019 Injection