Mitigating OWASP API Security Risk: Mass Assignment using F5 XC Platform

Overview:

This article is a continuation of the series of articles on OWASP API Security vulnerabilities and demonstrates a scenario for mitigating API Mass Assignment using F5 Distributed Cloud Platform (XC).

Introduction to OWASP API Mass Assignment:

APIs are the foundation building blocks for today’s modern applications and because of such high acceptance there are software frameworks available to help the developers with the implementation, but these frameworks sometimes allow developers to automatically bind client’s request parameters into the code variables, opening gates for the attackers to exploit the Mass Assignment vulnerability.

API Mass Assignment vulnerability occurs when manually crafted requests from clients to modify immutable internal object properties are not restricted by API Endpoints.

Attackers can take advantage of this vulnerability by framing an HTTP request to escalate user privilege, bypass security mechanisms or use any other approach to make the API Endpoints work in a way it was not designed to work.

Note: Mass Assignment and Excessive Data Exposure which were a separate risk category in OWASP API Sec 2019 are now merged into a new risk category named Broken Object Property Level Authorization

The above image is the pictorial representation of possible exploitation of Mass Assignment vulnerability. You can see the attacker is successfully able to escalate his privilege from normal user to admin by manipulating the JSON content of the API request.

In the first step, the attacker sends a valid API request to add the user and gets a response back with a parameter carrying information about the role.

In the second step, the attacker adds the role parameter to the JSON object in the API request eventually resulting in successful exploitation of the vulnerability.

Prevention Steps:

Automatic binding of client’s input data into application's internal code variables should be avoided.
Allow/Deny list should be clearly defined for the properties that should or shouldn't be accessible by the clients.
Application schema should be well defined and enforced on all incoming client requests.

Demonstration:

For this demonstration we’ve already hosted crAPI (completely ridiculous API) application by referring to the QuickStart guide in the repository.

Also, in the XC console we added the hosted application as an origin server and attached it with the newly created HTTP Load Balancer (LB).

Note: crAPI is a vulnerable application designed for training purposes and can be a helpful tool to understand the OWASP top 10 most critical API security risks. For more details you can refer to OWASP crAPI repository

Attack Scenario:

In the use case below we have an API endpoint which is used to order products. This endpoint has a vulnerable field named “quantity” that can be exploited for mass assignment by providing a negative value resulting in a successful purchase order with an increase in available balance.

As shown below at the start of the demo, the available balance for a user account is 200 $.

Step1: First step is to gather the endpoint and request payload data by placing a valid purchase order from GUI.

In the above screenshot, you can see we have successfully placed the order from the GUI which resulted in a decrease of available balance by 10$. This is a valid customer use case scenario.

Step2: Next, we will try to place an order for a product with negative quantity using the gathered endpoint and check if mass assignment vulnerability is present or not.

As you can see in the above screenshot the order with the negative quantity is placed successfully and the available balance is increased by 10$ which is not expected. Hence, we can conclude that mass assignment vulnerability exists in this demo application.

Prevention through F5 XC:

As mentioned in the prevention steps for the purpose of schema validation we will upload OpenAPI specification file to XC and set up the validation rules on incoming client requests

If a mismatch occurs, an API Security event will be triggered and based on the enforcement mode set in the validation rules, the request will either get reported or blocked.

Step1: As shown in the below image, update the crAPI’s OpenAPI specification file (a.k.a. swagger file) by adding a “minimum” keyword with value as “1” for the “quantity” parameter to restrict the request carrying a negative quantity to bypass

Step2: Import crAPI’s swagger file to the LB and create API Definitions

Login to F5 XC console
Navigate to your LB and start editing the applied configuration
Scroll down to API Protection and select “Enable” in API Definition field
Click “Add Item”, Enter a name
Click “Upload Swagger file”, Enter a name and upload the swagger file for your application, Apply the changes
Now from your LB main config page, select “Custom List” for “Validation” field and click Configure.
Start configuring Validation List, click “Add Item”, Enter a name, select “Validate” for “OpenAPI Validation Request Processing Mode” field, select “Block” for field “Request Validation Enforcement Type” and select all available properties in “Request Validation Properties” field, below of the config page select “Base Path - /” for “Type” field, Apply the changes. Refer to the document for more details.

Step3: Try to repeat the attack scenario of ordering a product with negative quantity.

As you can see in the above screenshot the attack was blocked successfully by the XC.

Step4: Monitor the “Security Analytics” logs from F5 XC console

Conclusion:

API Mass assignment vulnerability can illegally be exploited by attackers to cause some serious damage but as demonstrated, F5 XC API security solutions can help to detect and mitigate such vulnerabilities with the help of Open-API schema validation feature.