Broken Object Level Authorization (BOLA) is an access control vulnerability that allows attackers to access resources they should not have permission to access by manipulating the object IDs in requests. This vulnerability often occurs in APIs, as servers typically rely on the object IDs sent by the client to determine which objects a user can access, without performing proper permission checks.
Let's imagine an online banking app that lets users look at their account information. A user might ask to see their account like this: GET /account/12345. But what if the app doesn't check if the user is allowed to see that account? This could be a problem. A bad person might try to change the request to see someone else's account. For example, they might try GET /account/67890. The banking app needs to ensure that each user can only see their own account information; otherwise, it could lead to information leakage.
In the latest OWASP Top 10, the broken access control has risen from fifth place in 2017 to first place in 2021, becoming the most critical web application security risk. This vulnerability occurs when users can perform actions beyond their intended permissions, potentially leading to unauthorized information disclosure, modification, or data destruction.
What are the Common Issues Caused by BOLA Vulnerabilities?
Issues that may arise from BOLA vulnerabilities include:
- Data Leakage: Attackers can access data belonging to other users. For example, an attacker might access other patients' medical records in a healthcare application by modifying the patient ID.
- Account Takeover: In some cases, unauthorized access to objects can lead to the takeover of an entire account. For instance, an attacker might access and control a vehicle that does not belong to them by modifying the Vehicle Identification Number (VIN).
- Data Loss or Corruption: BOLA vulnerabilities can also result in data alteration or deletion. For example, an attacker might delete documents belonging to other users in a cloud storage service by modifying the document ID.
- Disruption of Business Processes: In e-commerce platforms, attackers might manipulate store names to access sales data from thousands of online stores, disrupting normal business operations.
- Increased Operational Costs: Attackers may exploit BOLA vulnerabilities to conduct denial-of-service attacks, consuming API resources with a large number of unauthorized requests, leading to increased costs for service providers.
What are the Principles of BOLA Vulnerability Attacks?
Reasons for the occurrence of BOLA vulnerabilities:
- API Endpoints Receive Object IDs: API endpoints receive an object's ID, which may be passed through the URI, request headers, or request body. A BOLA vulnerability may exist if the API does not check the caller's permission to access that resource.
- Lack of Proper Permission Checks: The API does not verify whether the logged-in user has the right to perform the requested operation on the requested object before executing it. This often occurs when server components do not fully track the client state and instead rely on parameters like object IDs sent by the client to determine which objects can be accessed.
- Ease of Exploitation: Once an attacker identifies a BOLA vulnerability, exploiting it using simple scripts is often easy. The attacker only needs to swap their own resource ID with the resource ID belonging to another user in the API call.
- Leads to Sensitive Information Disclosure: BOLA vulnerabilities can lead to the disclosure of sensitive information to unauthorized third parties, data loss, or data tampering. In some cases, unauthorized access to objects may also result in the takeover of an entire account.
In summary, the lack of comprehensive user authentication and parameter encryption during the software development process allows some users to exploit loopholes and arbitrarily modify access permissions. The diagram below shows that User A can only access Resource A. When the program's authentication is incomplete, the user may construct an API to access Resource B, thereby gaining access to and even modifying Resource B.
How to Prevent BOLA Vulnerabilities?
Here are some key measures to prevent BOLA vulnerabilities. By implementing these precautions, the risk of BOLA vulnerabilities can be significantly reduced, protecting APIs from unauthorized access and operations.
| No. | Preventive Measure | Description |
|---|---|---|
| 1 | Implement Object-Level Authorization Checks | Verify whether the user has permission to operate on a specific object before executing actions at each API endpoint. |
| 2 | Use Random and Unpredictable IDs | Avoid using sequential integers or easily guessable IDs to reduce the chances of attackers predicting or manipulating resource identifiers. |
| 3 | Limit Automatic API Creation | Avoid using tools that automatically generate API endpoints, ensuring that each endpoint adheres to the access control model. |
| 4 | Track and Manage API Endpoints | Conduct regular security audits and penetration tests to identify and fix potential security vulnerabilities. |
| 5 | Use an API Gateway | Install an API gateway as a single entry point for all API requests to apply security policies. |
| 6 | Implement Strong Authentication and Authorization | Use industry-standard authentication protocols such as OAuth 2.0, JWT, etc., and implement role-based access control. |
| 7 | Use a Web Application Firewall (WAF) | A WAF provides an additional layer of protection for enterprise APIs against common web application attacks. |
| 8 | Data Validation | Filter all content accepted by the server and validate parameters using XML or JSON schemas. |
| 9 | Rate Limiting | Limit the number of requests a user or IP address can make within a certain timeframe to prevent brute force and DoS attacks. |
| 10 | Security Testing | Regularly conduct API security testing, such as penetration testing, injection testing, and user authentication testing, to identify and address vulnerabilities. |
| 11 | Monitoring and Patching | Regularly monitor for abnormal network activity in APIs and update APIs with the latest security patches, bug fixes, and new features. |
| 12 | Sensitive Data Encryption | Use SSL/TLS encryption protocols to protect communication between APIs and client applications, and encrypt stored sensitive data. |
| 13 | Access Control Lists (ACL) | Use ACLs to control user access to specific resources. |
| 14 | Principle of Least Privilege | Ensure that users have only the minimum permissions necessary to complete their tasks, avoiding excessive privileges. |
| 15 | Education and Training | Provide security awareness training for developers to ensure they understand how to design and implement APIs securely. |
Conclusion
BOLA is a common security flaw that can lead to sensitive data leaks or unauthorized actions. When designing and building apps, developers need to make sure they control access to all objects properly to prevent this kind of problem. We need to put more effort into solving and preventing these issues during development and testing. Another option is to choose powerful third-party solutions to help us address these concerns.
Tencent EdgeOne offers robust web attack protection, effectively intercepting various threats. With an extensive attack signature database, it can reduce the risks of web attacks, exploits, trojans, backdoors, and other security issues. We have now launched a free trial and welcome you to register or contact us for more information.
FAQs
Q1: How does BOLA relate to IDOR?
A1: BOLA is closely related to IDOR (Insecure Direct Object References). They essentially refer to the same type of vulnerability, where an attacker can access or manipulate objects belonging to other users due to insufficient authorization checks.
Q2: Why is BOLA considered a significant security risk?
A2: BOLA is ranked as the number one vulnerability in the OWASP API Top 10 list. It's one of the most prevalent vulnerabilities in APIs, potentially exposing sensitive data and allowing unauthorized access to user information.
Q3: Can you provide an example of a BOLA vulnerability exploit?
A3: The Peloton security incident is a example of a BOLA exploit. Attackers were able to view all data, including private information, of other users due to insufficient object-level authorization.
Q4: How can developers prevent BOLA vulnerabilities?
A4: To prevent BOLA vulnerabilities, developers should implement proper object-level authorization checks. This includes validating user permissions for each object access request and ensuring that users can only access objects they are authorized to view or modify.