Mitigating OWASP API Security Risk: Mass Assignment using F5 BIG-IP
This article is a continuation of the OWASP Top 10 API Security series. It aims to explain Mass Assignment and how to stop it using F5 BIG-IP Advanced WAF. Introduction to Mass Assignment: In today’s world of data communication, applications often interact with one another to enable data sharing and improve services to meet user needs. At the core of these interactions are APIs, which are extensively utilized in modern application development. To streamline their implementation, developers commonly rely on various software frameworks. However, these frameworks often introduce a security risk by automatically binding client-provided data to code variables and internal objects without proper validation. This lack of validation creates an opportunity for an attacker to exploit a vulnerability known as Mass Assignment. In the screenshot mentioned above, describes the exploitation of Mass Assignment vulnerability. Attacker has successfully escalated his role from normal user to admin by modifying the JSON content of the API request. At first, the attacker sends a valid API request to the vulnerable application to add the user and gets a response back with a parameter that defines the role. In the second step, the attacker tampers the role parameters and sends the API request, due to lack of validations at the web server. This results in successful exploitation of the system. Preventive Steps: Automatic binding of client-input data into application’s internal code variables must be avoided. Clearly defining input parameters that should be allowed/blocked from the client-input data. Schema should be explicitly defined and enforced for the input parameters. Demo Attack and Mitigation steps using BIG-IP Advanced WAF: Using BIG-IP Advanced WAF, we define schemas with fixed parameters and only those are allowed from the client-input data and block the rest, thereby causing restrictions to the parameters that make the system vulnerable. The steps mentioned below give some brief details about creating a security policy using WAF policy API Security templates, which are designed to protect web applications that expose APIs from vulnerabilities. It focuses on safeguarding API endpoints, managing authentication, controlling access, and mitigating threats that target API logic and data handling. We generate a mass assignment attack followed by enforcing blocking mode to block the attack using BIG-IP. Let us now see a quick demo of mass assignment and mitigate it using BIG-IP Advanced WAF policy API Security template. Note: Following configs and validations are done on F5 BIG-IP VE with version: BIG-IP 16.1.6 Build 0.0.3 As a vulnerable application to exploit mass assignment, I chose crAPI demo application. Demo app crAPI Github repo Note: Before proceeding further into the demo, let us restrict the “quantity” value to 1 by adding a “minimum” keywork with value as 1 in the crAPI’s OpenAPI specification file or swagger file to positive values before uploading it to BIG-IP while creating a policy. Let’s try to violate the quantity value with input parameters and observe the behavior during Transparent and blocking mode. Step 1: Creating a security policy On the Main tab, click Security > Application Security > Security Policies. Click on Create to create the policy. Provide a name in the Name field. Make sure the Policy Type is Security. From the Policy Template, select API Security. The OpenAPI (Swagger) File field is now visible. Click Upload File to navigate to your OpenAPI specification file and upload it. From the Virtual Server dropdown, select the virtual server to which this policy should be assigned. Under Learning and Blocking section, make sure Enforcement Mode is initially set to Transparent to observe the attack requests. Click on Save to save the security policy configured. This confirms security policy is saved successfully. Step 2: Attack Generation and Mitigation In the demonstration below, we have an API endpoint which is used to order products. This endpoint has a vulnerable object named “quantity”. By providing negative value to this variable not only results in successful ordering of a product but also causes increment in available balance. This results in successful exploitation of mass assignment. As shown above, the available balance for a user is $200. From the above screenshot, you can be able to see on placing the order worth $10 successfully shows available balance as $190, which is expected behavior. Now, let us try to place an order for the same product with negative quantity for the same endpoint and check whether mass assignment vulnerability is present or not. As you can be able to see from above screenshot, order is successfully placed by providing client-input variable “quantity” with negative value and increment in available balance by $10 which is not expected. This confirms that mass assignment vulnerability exists in this demo application. BIG-IP logs show alarm for the above request in transparent mode. Now, let’s modify the policy to Blocking mode and observe the behavior. From the Policy configuration, Select Enforcement mode as Blocking, click on Save and then click on Apply Policy button. Once the policy is updated, and re-trying the same attack, the attack request is blocked. Conclusion: Mass assignment vulnerability provides an opportunity for attackers to exploit the vulnerability using client-input variables. BIG-IP Advanced WAF’s OpenAPI schema validation feature helps to detect and mitigate these vulnerabilities, thereby safeguarding the application and enhancing overall security of the system. References: For more detailed guidance on OWASP and steps to configuring Advanced WAF security policy on F5 BIG IP, refer to the official documentation below: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ https://techdocs.f5.com/en-us/bigip-17-0-0/big-ip-asm-implementations/working-with-openapi.htmlMitigating Log4j Vulnerability using F5 BIG-IP
This article throws some light on the Apache Log4j vulnerability (CVE-2021-44228) and how attackers can exploit this vulnerability by injecting malicious JNDI strings into input fields, HTTP headers, API requests, etc. Finally we also provided solution how we can protect it using F5 Advanced WAF.
