|
| 1 | +--- |
| 2 | + |
| 3 | +layout: col-document |
| 4 | +title: WSTG - Latest |
| 5 | +tags: WSTG |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +{% include breadcrumb.html %} |
| 10 | +# API Broken Function Level Authorization |
| 11 | + |
| 12 | +|ID | |
| 13 | +|------------| |
| 14 | +|WSTG-APIT-03| |
| 15 | + |
| 16 | +## Summary |
| 17 | + |
| 18 | +Broken Function Level Authorization (BFLA) occurs when an API improperly enforces restrictions on users accessing certain functions or operations. This vulnerability allows attackers to invoke sensitive functions they are not authorized to execute, such as administrative functions or other high-privilege operations. |
| 19 | + |
| 20 | +BFLA commonly arises when APIs expose multiple endpoints that serve different user roles (e.g., user vs. admin) but fail to restrict access to these functions based on the user's authorization level. |
| 21 | + |
| 22 | +Exploiting BFLA can lead to serious consequences such as privilege escalation, unauthorized access to sensitive functions (e.g., administrative operations), or exposure of critical functionalities that should only be accessible to specific user roles. |
| 23 | + |
| 24 | +## Test Objectives |
| 25 | + |
| 26 | +- The goal of this test is to determine if the API enforces **role or privilege-based access control** to restrict users from accessing or executing functions they are not authorized to use. This ensures that function-level security boundaries are properly enforced. |
| 27 | + |
| 28 | +## How to Test |
| 29 | + |
| 30 | +### Identify Function-Level Endpoints |
| 31 | + |
| 32 | +Review API documentation (e.g. OpenAPI specification), traffic, or use an interception proxy (e.g., **Burp Suite**, **ZAP**) to identify different function-level endpoints. These might include: |
| 33 | + |
| 34 | +- **Administrative functions** (e.g., `/api/admin/deleteUser`, `/api/admin/getAllUsers`) |
| 35 | +- **Role-based operations** (e.g., `/api/admin/promoteUser`, `/api/user/createOrder`) |
| 36 | +- **Critical functions** for users (e.g., `/api/user/withdrawFunds`) |
| 37 | + |
| 38 | +Focus on **functionality differences** between different user roles (e.g., regular user, admin, partner, guest) and endpoints that offer more sensitive capabilities. |
| 39 | + |
| 40 | +### Manipulate Role-Based Access Controls |
| 41 | + |
| 42 | +Try to access or perform sensitive operations exposed in API endpoints that should be restricted based on user roles. |
| 43 | + |
| 44 | +Log in as a lower-privilege user (e.g., guest or regular user) and send requests to endpoints that perform sensitive actions reserved for higher-privilege roles (e.g., admin). |
| 45 | + |
| 46 | +Example: as a **regular user**, send a request to the following administrative endpoint to delete a random user: |
| 47 | + |
| 48 | +```http |
| 49 | +POST /api/admin/deleteUser |
| 50 | +Authorization: Bearer <regular_user_token> |
| 51 | +
|
| 52 | +{ "userId": "12345" } |
| 53 | +``` |
| 54 | + |
| 55 | +### Test Function-Level Access with Different HTTP Methods |
| 56 | + |
| 57 | +Test various **HTTP methods** for BFLA vulnerabilities: |
| 58 | + |
| 59 | +- **GET**: Attempt to access information available only to high-privilege users (e.g., administrators). |
| 60 | + - Example: `GET /api/admin/getAllUsers` |
| 61 | +- **POST/PUT/PATCH**: Attempt to modify or create sensitive resources (e.g., changing user roles, creating or deleting system-critical data). |
| 62 | + - Example: `POST /api/admin/promoteUser { "userId": "12345", "newRole": "admin" }` |
| 63 | +- **DELETE**: Attempt to delete sensitive resources, such as removing user accounts or data. |
| 64 | + - Example: `DELETE /api/admin/deleteUser/12345` |
| 65 | + |
| 66 | +### Test for BFLA in GraphQL APIs |
| 67 | + |
| 68 | +In **GraphQL APIs**, test if a user can invoke functions restricted to higher-privilege roles by modifying GraphQL queries. |
| 69 | + |
| 70 | +Example: `mutation { deleteUser(id: "12345") { success } }`. |
| 71 | + |
| 72 | +## Indicators of BFLA |
| 73 | + |
| 74 | +- **Successful exploitation**: If a lower-privilege user (e.g., regular user or guest) can execute high-privilege functions or perform actions reserved for other roles (e.g., admin). |
| 75 | +- **Error responses**: Properly secured APIs in general would return `403 Forbidden` or `401 Unauthorized` when invoked restricted functions instead of a `200 OK` response. |
| 76 | +- **Inconsistent enforcement**: Some endpoints enforce role-based restrictions while others do not, which indicates inconsistent security controls. |
| 77 | + |
| 78 | +## Remediations |
| 79 | + |
| 80 | +To prevent BFLA vulnerabilities, implement the following mitigations: |
| 81 | + |
| 82 | +- **Enforce Role-Based Access Control (RBAC)**: Ensure that the API checks user roles and permissions at the **function level** before allowing access to certain operations. Only authorized roles should be allowed to invoke sensitive functions. |
| 83 | +- **Least Privilege Principle**: Apply the principle of least privilege by ensuring that users can only access the minimum set of functions they need for their role. |
| 84 | +- **Centralized Access Control Logic**: Use centralized access control logic to ensure consistency across all API endpoints. This avoids gaps where some functions may lack proper access checks. |
| 85 | + |
| 86 | +## Tools |
| 87 | + |
| 88 | +- **ZAP**: Use automated scanners and manual proxy tools to inspect API requests and responses for BFLA vulnerabilities. |
| 89 | +- **Burp Suite**: Use **Repeater** or **Intruder** to send requests as lower-privilege users to test if function-level restrictions are enforced. |
| 90 | +- **Postman**: Manually send API requests as different user roles and observe responses. |
| 91 | +- **Fuzzing Tools**: Use fuzzers to test different function parameters and methods to identify potential authorization weaknesses. |
| 92 | + |
| 93 | +## References |
| 94 | + |
| 95 | +- [OWASP API Security Top 10: BFLA](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/) |
| 96 | +- [OWASP Testing Guide: Testing for Privilege Escalation](../05-Authorization_Testing/03-Testing_for_Privilege_Escalation.md) |
| 97 | +- [OWASP Testing Guide: Testing for GraphQL](99-Testing_GraphQL.md) |
0 commit comments