BFLA: How to test Broken Function Level Authorization by Changing the HTTP Method Using Akto?
The Equifax data breach in 2017, which exposed the personal information of 143 million individuals, was a result of a vulnerability in the Apache Struts API framework and a broken functionality level authorization (BFLA) in Equifax's web application.
Medusa
8 mins read
Attackers were able to gain unauthorized access to sensitive data by exploiting the misconfigured API and bypassing the flawed BFLA mechanism, which should have restricted access to certain functionality.
This incident highlights the crucial role of API security in protecting web applications from unauthorized access. APIs are frequently targeted by attackers because they provide a direct means of interacting with the application's backend. As such, it is critical to test API endpoints for vulnerabilities.
Overview BFLA
What is BFLA?
BFLA by Changing the HTTP Method
How to Manually Test for it?
Automation Using Akto
Prevention
What is Broken Functionality Level Authorization?
Broken Functionality Level Authorization (BFLA) is a vulnerability that allows unauthorized access to certain functionalities or resources within an application. This can occur when an application does not properly validate user privileges or roles, allowing a user to access functionality they are not authorized to use.
BFLA is one of the OWASP Top 10 API Vulnerabilities. Therefore, it is crucial to test for it from a security standpoint.
BFLA can be exploited in different ways depending on the type, and for the purposes of this blog, we will be specifically focusing on the method of exploiting BFLA by changing the HTTP request method.
How to find BFLA Vulnerability?
The most effective way to discover BFLA vulnerabilities in an API endpoint is to identify endpoints that have specific functionalities, such as login, registration, feedback, and image deletion etc. Analyze the requests and responses of these endpoints. The recommended tool for this task is BurpSuite.
There are two ways to analyze API endpoints:
If you have an API collection, you can analyze its requests and responses in Postman.
If you don't have an API collection, turn on the proxy and capture all the requests of the target application by interacting with different functionalities in BurpSuite.
To perform the test, follow these steps:
Identify the endpoints that have functionality to perform some action. This could be an endpoint that creates a user, updates a user, deletes a user, send a feedback or adding something to the cart.
Analyze the response of the functionality to determine if it returns data related to the user. This could include data such as the user's name, id, email, or account information.
How to exploit manually?
To perform this, follow the steps below:
Once you have identified a number of potential endpoints that perform actions based on the user's data in the JSON body of the request, you can start exploring each one in detail to ensure that you have a thorough understanding of what each endpoint does and how it interacts with the data in the JSON body.
Change the HTTP method from POST to a different method, such as GET, PATCH, or PUT, and then send the request.
If the API response includes additional data that a regular user should not have access to (for example, sensitive information), then the endpoint is vulnerable.
Practical Demonstration
Target Application: OWASP Juice Shop
The target application has a "Customer Feedback" feature, which allows users to provide comments and ratings, solve a captcha, and submit their feedback. However, there is no visual confirmation displayed after the feedback is submitted.
To view the request, we can capture it in BurpSuite. We can see that the API endpoint is /api/Feedback.
Send the request to the repeater, and in the response, you can see that the API endpoint returns some data in JSON format. This data pertains to the user who submitted the feedback, which includes their unique ID, rating, and feedback.
Also, note that the HTTP method is "POST." To test BFLA, simply change the HTTP method from POST to GET and send the request.
Send the request to the repeater, and in the response, you can see that the API endpoint returns some data in JSON format. This data pertains to the user who submitted the feedback, which includes their unique ID, rating, and feedback.
Also, note that the HTTP method is "POST." To test BFLA, simply change the HTTP method from POST to GET and send the request.
Time Consumption
Testing for BFLA by changing the HTTP method is not difficult, but it can be a tedious and time-consuming task.
"There are nine commonly used HTTP methods: GET, POST, PUT, DELETE, HEAD, OPTIONS, CONNECT, TRACE, and PATCH."
For example, if you have 890 API endpoints with functionalities, you would need to perform 8010 tests (890 x 9). This is insane!
Automation Using Akto
Akto can make this task easier for you by scanning thousands of endpoints with just one click!
If you have not yet installed Akto, you can do so from the Akto GitHub page along with the Akto extension in Burp Suite. For demonstration purposes, we will use OWASP Juice Shop.
Akto Burp Extension
There are multiple ways to create an API inventory in Akto that work in both the Community and Professional editions. You can import a .har file, use Postman, or forward traffic from BurpSuite to do so.
In this case, we are going to create an API inventory through Akto Burp Extension. Simply browse the application and capture all the endpoints.
From the screenshot above, we can see that Akto extension has captured all the requests.
After creating your API inventory in Akto, click on "Run Test" and select the "BFLA by changing the HTTP Method" test. Make sure to uncheck any other vulnerabilities.
Click on “Run Once Now” and click on the Testing section to see the results.
The Akto engine was able to identify the vulnerability, and its severity is high.
By clicking on the "Attempt" section, we can see that the POST HTTP method has been changed to GET in order to exploit the vulnerability.
By clicking on the "Attempt" section, we can see that the POST HTTP method has been changed to GET in order to exploit the vulnerability.
When to use Burp vs Akto?
Both manual and automated testing are helpful for detecting vulnerabilities such as verb-tunneling in an API endpoint. When you have just deployed a new API inventory, start by testing in Akto to cover all the popular BFLA vulnerability attacks. After you finish testing, manually explore the critical APIs in Burp to find vulnerabilities you couldn’t find using Akto. This approach can help you save time and focus on critical endpoints.
How to Prevent BFLA?
Preventing broken functionality level authorization (BFLA) by changing the HTTP method can be achieved by taking the following steps:
Validation of HTTP Methods: Verify that the HTTP method used for a given request is permitted for the relevant functionality or data. For instance, if a user is only authorized to view data, do not permit them to use the HTTP PUT method to modify that data. Example:
Use a whitelist approach - Define a list of allowed HTTP methods for each functionality, and restrict all other HTTP methods. This can be achieved by configuring the application server or web application firewall to only allow specific HTTP methods for each endpoint.
Test your APIs for function-level authorization vulnerabilities by attempting to access all privileged APIs with less privileged roles, and verifying that access is denied for unauthorized users.
Set up a Semgrep rule to have a few basic checks on source code such as:
Every API has a role defined to it
Any
PUT/POST/PATCH APIshould not be given to a Read-only role etc
If there is an admin panel in your application, exclusively meant for internal employees only, then it should be accessed preferably via a VPN.
Test your APIs against function-level authorization vulnerability. Hit all the privileged APIs with lesser privileged roles and ensure none work.
Getting Started
Start your API security scanning with Akto. You can download it from the GitHub page and follow the instructions for a successful installation. Also, don't forget the BurpSuite Akto extension, which you can download by following the steps from here.
Looking forward to hearing from you. Please let us know if you have any ideas that you would like us to include.
Happy API security testing!
Keep reading
API Security
8 minutes
Security Information and Event Management (SIEM)
SIEM aggregates and analyzes security data across an organization to detect, monitor, and respond to potential threats in real time.
News
8 mins
Akto Recognized as a High Performer in G2’s Fall 2024 Reports for API Security and DAST
We’re proud to announce that Akto has been named a High Performer in both the API Security and Dynamic Application Security Testing (DAST) in G2’s Fall 2024 reports.
Product updates
5 minutes
Introducing Akto Code: Automated API Discovery from source Code
Akto Code is the new addition to Akto's API Discovery suite, complementing our existing capabilities for traffic source analysis in production and lower environments.