Broken Function-Level Authorization: How It Works and 4 Preventive Measures

This is part of a series of articles about OWASP top 10 API.

‍

Broken Function Level Authorization vs. Broken Object Level Authorization 

Broken Function Level Authorization and Broken Object Level Authorization (BOLA) both deal with improper enforcement of access controls, but one focuses on unauthorized access to functionality, while the latter deals with access to objects or data. BFLA is about functions or actions a user can perform, while BOLA involves accessing, modifying, or deleting specific data entities.

BFLA can significantly compromise system integrity and confidentiality by allowing unauthorized users to perform actions they are not entitled to. This can lead to unauthorized data manipulation, privilege escalation, or access to restricted functionalities, potentially affecting the entire application or system. The risk is especially high in systems where functionalities are closely tied to sensitive operations or data.

BOLA affects data confidentiality and integrity on a more granular level. Unauthorized access to specific objects or data records can lead to data breaches, unauthorized data modifications, or deletion. The impact is limited to the affected data entities, but can have broader implications if the exploited objects are critical to the application's functionality or security.

‍

How Do BFLA Attacks Work? 

A BFLA attack involves the following steps:

1. Exploration and Mapping

Attackers begin by identifying the system's functionalities and mapping out accessible features. They explore the application, noting available actions and endpoints for different user roles. This phase often involves analyzing the application's traffic and response behavior to understand its structure.

The exploration aims to discover functions that lack proper access controls. Attackers catalog these functions for potential exploitation, focusing on sensitive or critical operations. Tools and scripts may automate this process, increasing efficiency in mapping vulnerabilities.

2. Role Comparison and Access Testing

Attackers compare the access levels of different user roles to find discrepancies or functions accessible beyond intended permissions. Testing involves simulating requests or actions as users of lower privileges to access functionalities restricted to higher roles.

This step confirms vulnerabilities identified during exploration. Attackers systematically test each function for improper authorization checks, verifying which actions can be performed without authorization. Successful tests indicate a BFLA vulnerability.

3. Exploitation of Misconfigurations

Upon identifying exploitable functions, attackers craft requests that bypass authorization checks. This usually involves manipulating request parameters or exploiting server-side misconfigurations to access or execute restricted functionalities.

During exploitation, attackers directly access or alter data and functionalities. Successful exploitation allows unauthorized operations, such as administrative actions or accessing sensitive information, underscoring the critical nature of these vulnerabilities.

4. Leveraging the Attack

After successful exploitation, attackers leverage unauthorized access for malicious purposes. This could include data theft, account takeover, service disruption, or further system exploitation. The extent of an attack's impact depends on the nature of the exploited functionality and the attacker's objectives.

‍

Example of a BFLA Attack

The example below is adapted from the official OWASP API security guide.

Consider an application that requires an invitation to join. The application makes an API call to its server to retrieve the invitation details using a specific link, like this:

GET /api/invites/{invite_guid}

The response provides a JSON object showing the invitee's email and their designated role within the app.

However, a security flaw is exploited when an attacker mimics this request. They change the method from GET to POST, targeting a different link: 

POST /api/invites/new

This action should only be possible for the app's administrators through a special admin area, yet there are no checks to verify who's making the request.

By abusing this flaw, the attacker sends a request that issues them an invitation with administrator rights:

POST /api/invites/new

{
  "email": "attacker@somehost.com",
  "role": "admin"
}

Using this unauthorized invitation, the attacker is then able to set up an admin account, granting them complete control over the app.

‍

4 Ways to Prevent Broken Function Level Authorization Vulnerabilities 

Fortunately, there are some measures that can help prevent BFLA attacks by minimizing the presence of vulnerabilities.

1. Function-Level Validation

Function-level validation entails verifying user permissions before processing any function or action request. Validation mechanisms ensure users can only execute functions aligned with their roles and privileges.

Proper implementation requires a secure design from the initial development phases, integrating comprehensive permission checks throughout the application. It also involves continuous updates to validation logic as new functionalities or roles are introduced.

2. Secure Session Management

Secure session management involves securely handling user sessions to prevent unauthorized access or session hijacking. Proper session management ensures that only authenticated users can access their permitted functionalities.

Techniques include implementing timeouts for inactive sessions, encrypting session data, and securely managing session tokens. Ensuring sessions are managed securely can significantly mitigate risks associated with BFLA by restricting function access to legitimately logged-in users.

3. Manage All Administrative Access

Strict controls should govern who can perform administrative actions, under what conditions, and through secure protocols. This prevents unauthorized access to critical functions and helps detect and respond to potential BFLA threats faster.

Best practices include using role-based access control (RBAC), enabling multi-factor authentication (MFA) for administrators, and logging all administrative activities. These measures provide layers of security against unauthorized function access and misuse.

4. API Security Testing

Regular API security testing is essential for identifying and mitigating BFLA vulnerabilities before they can be exploited. This involves conducting automated and manual tests to evaluate the security of API endpoints against unauthorized access and other potential threats. 

Automated tools can scan for common vulnerabilities, such as those related to authentication and authorization. Advanced API testing tools enable deeper analysis and the identification of logic-specific issues that depend on application context, which is common for BFLA vulnerabilities.

‍

API Security with Pynt

Pynt's approach to API security emphasizes a 'shift-left' methodology, focusing on early discovery and resolution of vulnerabilities. This proactive stance in the software development life cycle allows for:

• Early Detection: Identifying API vulnerabilities early in the development process, reducing potential security risks.
• Leverages functional tests to detect complex business logic scenarios, providing targeted security insights.
• Seamless Integration: Facilitating easy integration with existing development tools and pipelines, enhancing developer productivity without compromising security.
• Comprehensive API Discovery: Automated discovery of APIs, ensuring complete visibility from development to production, crucial for identifying shadow APIs and other hidden risks.

These aspects collectively enhance the overall security posture by addressing API vulnerabilities at their inception, rather than as an afterthought.

Learn more about Pynt

‍