API5:2023 Broken Function Level Authorization (BFLA)
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 similarities to broken object level authorization (BOLA) in this regard.
Attackers can discover these flaws in APIs because 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.
These flaws can be exploited by sending legitimate API requests to an API endpoint that the attackers 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.
What is the difference between BOLA and BFLA?
Broken function level authorization (BFLA) can be considered a higher-level version of broken object level authorization (BOLA). The main difference is that, when exploiting a BFLA vulnerability, an attacker focuses on general API functions rather than individual API objects. The consequence of BFLA is that clients can access functionality beyond their intended access level, such as administrative functions.
Attackers will attempt to exploit both vulnerabilities when targeting APIs in order to escalate privileges horizontally or vertically.
Learn how to secure APIs in dev and runtime and enable a model of continuous improvement
Download NowPotential Impact of a Broken Function Level Authorization Attack
Broken function level authorization (BFLA) has been identified as the fifth most critical threat to APIs in the OWASP API Security Top 10, and for good reason. In fact, 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.
What Does a BFLA Attack Look like?
Real World Example: New Relic Synthetics
In 2018, cyber researcher Jon Bottarini found that a restricted user could make changes to alerts on New Relic Synthetics monitors without the proper permissions to do so. In fact, they could make changes with no permissions at all because of the privilege escalation weakness that was present in the product at that time. Exploitation involved submitting a legitimate request to an API endpoint that was otherwise not visible to the restricted user.
As part of his security research, Bottarini captured traffic of a privileged session using an intercepting proxy tool, Portswigger Burp Suite. This traffic included a POST request to an API endpoint and function that creates alerts on Synthetics monitors. He found that you could trap a GET request from the non-privileged session, retain the tokens and cookies for that restricted user, and alter the remainder of the trapped request to resemble the privileged POST request. This manipulation of API traffic to access functionality not visible in the UI (at all or to that user and their permissions) is a common technique attackers use to exploit function level authorization weaknesses and escalate privileges.
Why Existing Tools Fail to Protect your APIs Against BFLA
Traditional security controls like WAFs and API gateways lack the context of API activity and therefore do not know that the attacker in the first 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 New Relic 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 your APIs from 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 first example above.
It is critical that an API security tool 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.
To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo.
