API security is a key consideration for modern software enterprises since hackers can abuse API vulnerabilities for various exploits. Out of various critical API security risks, the API Mass Assignment vulnerability (OWASP API 6:2019) ensues when the application binds client-provided information to its data models without proper filtering based on a whitelist. Attackers leverage this flaw to modify object properties they should not by guessing internal object properties, accessing product documentation, or providing additional object properties in request bodies.
This article discusses the impacts of API mass assignment vulnerability on modern application delivery, common examples, and possible prevention measures.
What is a Mass Assignment Vulnerability?
OWASP attributes the API mass assignment vulnerability as an input validation flaw that allows hackers to perform advanced attacks by manipulating payload data. The threat arises when the API endpoints save a request body as it is instead of extracting request parameters one by one. Malicious users typically exploit the flaw to initialize or overwrite server-side parameters that the developers never intend to expose.
A common development practice is to create a copy of the incoming request and save it in a database, as it seems appropriate for internal object sharing. However, the approach leads to a risky configuration since attackers can decipher the properties in request payloads and send additional parameters to change their effect on the API endpoint.
Mass Assignment Vulnerability – Impact & Attack Severity
The mass assignment vulnerability has an exploitability score of 2 (low) since the exploitation of mass assignment flaws requires a deeper understanding of internal object relations, business logic, and security configurations at the API endpoint level. The exploitability, however, increases if the attacker can infer sensitive properties, review object schema by reading source code, and the sensitive object has an empty constructor.
The vulnerability has a low prevalence since developers mostly build APIs using security best practices. The detectability of an attack is low (2) since modern application frameworks automatically bind data from client input into code variables, making it difficult to differentiate legitimate and malicious requests.
Since APIs expose the underlying implementation of the product, the vulnerability has a high technical impact (6). Some effects of a successful mass assignment attack include:
- Data tampering
- Privilege escalation
- Bypass of security mechanisms
Whitepaper
API Vulnerability Prevention Guide
Learn how to detect and prevent API vulnerabilities.
Mass Assignment Vulnerability Examples
Assigning values to multiple variables simultaneously allows malicious actors to orchestrate API endpoint-level cyber security attacks targeting stored object properties. Following are some standard techniques used in the exploitation of mass assignment vulnerabilities.
Mass Assignment: Insecure Binder Configuration
Spring MVC and ASP NET MVC frameworks allow HTTP parameters to map directly onto model objects. This allows malicious users to inject additional parameters as they desire.
Assume the application uses the following form to edit user information.
<form>
<input name="username" type="text">
<input name="password" type="text">
<input name="email" text="text">
<input type="submit">
</form>The form binds to the following object:
public class User {
private String userid;
private String password;
private String email;
private boolean isAdmin;
}A typical request for adding a user to the database would be similar to the following:
POST /addUser
...
username=darwinuser&password=hashedpass&email=darwin@domain.comAttackers can modify the user addition request for escalated privileges if the application is vulnerable to a mass assignment. The exploit to set the user’s account as an administrator involves adding the attribute isAdmin to the class User by modifying the request, as shown:
POST /addUser
...
userid=darwin&password=hashedpass&email=darwin@domain.com&isAdmin=trueObject injection
In PHP applications, the serialize() and unserialize() functions are used to store and load data with PHP types across various requests. While the feature is simple and effective, it introduces critical API security risks when user input is passed to the unserialize() function.
Consider the following PHP code snippet:
<?php
class LoggingClass {
function __construct($filename, $content) {
$this->filename = $filename . ".log";
$this->content = $content;
}
function __destruct()
file_put_contents($this->filename, $this->content);
}
}
$data = unserialize($_GET['data']);The above constructor passes user input directly to unserialize(). The LoggingClass constructor takes two parameters (file contents and a filename) to write to. The _destruct() method checks the log and writes it to the filename taken by the constructor.
Suppose the attacker takes control of the arguments sent to the unserialize() function. In that case, they can potentially send the following serialized payload, which sets the filename to shell.php and sets the content to a malicious PHP code:
O:12:"LoggingClass":2:{s:8:"filename";s:9:"shell.php";s:7:"content";s:20:"<?php maliciousCode(); ?>";}The above-shown sample payload creates a backdoor web shell that executes the additional code supplied by the attacker.
How to Prevent Mass Assignment Vulnerabilities
Techniques to prevent mass assignment issues in modern APIs include:
Allow Lists
Developers should create schemas that define all the patterns and types that can be included in an incoming request. When this schema is implemented at runtime, the application can only accept whitelisted properties, which eventually keeps malicious actors from injecting unintended object properties through modified request parameters. It is also recommended to allow-list the bindable, non-sensitive object properties and block-list the non-bindable, sensitive properties.
Data Transfer Objects
A Data Transfer Object is an architectural function that avoids binding user input into code variables and domain objects. The object is meant to hold the fields intended for user editing while encapsulating the serialization mechanism that transfers the input data payloads across the API interface.
Other common approaches for preventing mass assignment include:
- All fields that can be retrieved from the API request body and API response (but should not be modified by the user) should be set to read-only
- Continuous vulnerability scanning to identify and remediate any emerging input validation flaws
- Request body transformation techniques to modify request values into the desired output
FAQs
What is the difference between mass assignment and improper asset management?
Mass assignment is an input and authorization validation flaw that allows attackers to manipulate client-provided data for advanced exploits. A common attack pattern is to alter sensitive properties that attackers are not authorized to, allowing them to perform attacks such as command injection, privilege escalation, and data breaches.
On the other hand, improper asset management is a critical API security risk when developers fail to keep track of their API endpoints. With improper management of assets, developers are typically unaware of API vulnerabilities present in their deployments, allowing for easy, undetectable exploits.
Are there any benefits of mass assignment?
The mass assignment allows developers to assign multiple attribute values using a single operator. Apart from saving time to code, the approach also allows for the quick deployment of non-sensitive objects. The technique, however, is recommended to be restricted to non-sensitive object properties, as mass assigning sensitive properties will enable attackers to modify application logic for advanced attacks.
