LAST UPDATED September 21, 2023
No. 5 on the 2023 OWASP API Top 10 vulnerabilities list is broken function-level authorization. OWASP explains that this vulnerability often occurs “because authorization checks for a function or resource are usually managed via configuration or code level. Implementing proper checks can be a confusing task since modern applications can contain many types of roles, groups, or complex user hierarchies (e.g., sub-users, users with more than one role). It’s easier to discover these flaws in APIs since APIs are more structured, and accessing different functions is more predictable.” This confusion is why some applications inadvertently grant overly broad permissions, such as assigning all users with admin functionality instead of assigning role-based access controls to limit access to sensitive operations.
This vulnerability is similar to BOLA, but is concerned with access to functions, rather than individual objects. For example, an API might expose, as a function, the ability to add credit to a user’s account or alter audit logs. This functionality should be reserved for administrative users. But a broken authorization vulnerability in the software could result in that functionality being exposed to any authenticated user clever enough to leverage those functions without the proper authorization checks.
How Do Broken Function-Level Authorization Exploits Work?
This vulnerability really comes down to software design. If API endpoints are excessively permissive, if they are trustful that the clients will be authenticated and legitimate, then the endpoint may not implement enough protection of functions.
For instance, we frequently see endpoints that appropriately authenticate users on connection, but once a session is established, execute commands without checking to see if the authenticated user should have access to that command.
OWASP gives this example:
An API contains an endpoint that should be exposed only to administrators - GET /api/admin/v1/users/all. This endpoint returns the details of all the users of the application and does not implement function-level authorization checks. An attacker who learned the API structure takes an educated guess and manages to access this endpoint, which exposes sensitive details of the users of the application.
Broken function level authorization attacks can have serious consequences. Without the appropriate security checks around access to exposed functions, this attack can be very fruitful for the attacker resulting in data leakage, privilege escalation, or even account takeover.
How to Prevent Broken Function-Level Authorization
There are a few best practices in the development phase that can help prevent broken function level authorization vulnerabilities, including enforcing a standardized authorization strategy within all endpoints of your API, taking into account the user authorization level and the authorization requirements of all requested functionality, and executing access checks at every API call, not just at session initiation.
How ThreatX Can Help
One of the most common use cases ThreatX is called to help with is “already deployed” API endpoints that did not go through rigorous security-oriented design review prior to being rolled into production.
API attacks are often “door rattling” exercises. Attackers formulate attacks based on recon, and trial and error, until they get access to data they shouldn’t. ThreatX identifies this abnormal behavior, and ascribes risk ratings to seemingly innocuous traffic. If an entity accumulates a risk score past a certain threshold, we block that entity. So, in practice, we stop this sort of API attack by virtue of detecting API activity out of the norm for a given endpoint.
Additionally, our platform allows the creation of custom security tests that can virtually patch even poorly designed API endpoints, for instance, ensuring that API calls executing administrative functions are preceded by a page load that enumerates such capabilities, or a successful login to an administrative site.
We also track API error codes, and can tell when an attacker is initiating a spray-and-pray attack probing for broken function-level authorization vulnerabilities. We base this information on actual traffic being processed by customer endpoints, allowing us to highlight actual risk and actual attacks, rather than theoretical weaknesses in design.
And we stop the attack, which differentiates our approach from many solutions in the API protection space.
How Our Approach Is Unique
Real-Time Blocking
Some API security solutions simply highlight potential API vulnerabilities, leaving security teams to investigate and recommend code changes. Other API solutions can identify an attacking IP, but require security teams to try to model the complex behavior in a third-party WAF (or try to block one IP at a time after the fact). ThreatX doesn’t just tell you about your API vulnerabilities or attempted attacks like broken function-level authorization or attempts to exploit it; we also block API attacks in real-time. ThreatX proxies and scans all inbound API traffic – in real time – identifying and blocking attacks.
ThreatX recognizes attacker behavior indicative of an attempt to exploit broken function-level authorization, then flags and watches that user. This real-time monitoring enables ThreatX to execute advanced threat engagement techniques, such as IP interrogation, fingerprinting, and tarpitting. When a series of user interactions cross our default (or your customized) risk threshold, we block the attack.
Step One of N…
In many cases, attackers aren’t just going to attack with a broken function-level authorization exploit; they’re going to string together a series of attacks over time, often using federated and sophisticated botnets. Countering this approach requires the ability to correlate attack traffic across multiple IPs, the use of advanced bot protection, and the ability to detect identifiers and techniques to associate the traffic to a unique attacker. Rather than requiring a single, significantly risky event or identifying a known signature, ThreatX analyzes behaviors from multiple vantage points. This lets the ThreatX Platform identify and block more threats, more accurately than competing API security tools.
Less False Positives
As risk rises, ThreatX immediately blocks an attack – stopping the threat in its tracks. ThreatX’s blocking modes are designed to block malicious requests and deter suspicious entities from attacking your APIs, while allowing benign traffic and real users through. Legacy WAFs struggle with false positives because they only make blocking decisions based on rules, but attackers and legitimate users don’t always follow the rules. Sometimes a legitimate user who forgot their password looks like an attacker, and sometimes an attacker cycling through usernames and passwords looks like a legitimate user. ThreatX can tell the difference.
Learn more in Why an Attacker-Centric Approach Is Key to API Protection. Or request a demo of the ThreatX solution.
