What is Mass Assignment: How We Can Help

2023 UPDATE: In the 2023 OWASP API Top 10 vulnerabilities list, Excessive Data Exposure and Mass Assignment are combined into a new entry, Broken Object Property Level Authorization. OWASP made this change to focus on the root cause of these two vulnerabilities: the lack of or improper authorization at the object property level. This can lead to unauthorized parties getting access to or manipulating sensitive data.  

Get details on Broken Object Property Level Authorization.

OWASP says of mass assignment, “Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually leads to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.” 

Mass assignment exploits can be considered a variant of BOLA attacks. In both cases, a successful attacker is able to send requests containing unexpected data properties to valid endpoints in order to gain access to functionality not intended by the application developers. Unlike BOLA, mass assignment exploits apply specifically to APIs that deal with modifying a bulk collection of resources. 

How Do Mass Assignment Exploits Work? 

Mass assignment is actually a feature of many API server frameworks, and it’s intended to make life easier for API client developers. However, as OWASP mentions above, without proper properties filtering based on a set of allowed object properties, an attacker could modify private, internal, reserved, and/or hidden properties and gain access to sensitive data, typically through privilege escalation. 

For example, imagine an application containing an API endpoint allowing authorized users to update user information. This API functionality may have been intended for corporate accounts who need to make updates in bulk to coincide with personnel changes.

<pre>
<code>
POST /posts/bulkupdate  
{ "data": [ 
    {  
      "user_id": 123789, 
      "title_id": “VP of Sales”, 
      "email": "sales.vp@company.com, 
      ... 
    }, ... 
] } 
</code>
</pre>

But imagine this innocuous bulk-update were to be used by a malicious individual intent on causing mischief or worse: 

<pre>
<code>
POST /posts/bulkupdate  
{ "data": [ 
    {  
      "user_id": 123789, 
      "title_id": “VP of Sales”, 
      "email": "attacker@nefarious.com”, 
      ... 
    }, ... 
] } 
</code>
</pre>

In this hypothetical example, the attacker modifies the “email” property in order to update the user’s email to an attacker owned inbox. If the updated account has elevated permissions within the application and the attacker leverages the password reset functionality to send an updated password to their inbox, they now have elevated permissions within the application. 

This is a contrived example, but all mass assignment exploits rely on API validation logic, intended for typically mundane bulk-level functions, being misused to grant unintended powers to unauthorized clients. 

How to Prevent Mass Assignment 

Similar to BOLA, prevention starts with defensive programming techniques, such as enforcing a standardized authorization strategy within all endpoints of your API, taking into account the user authorization level and the authorization requirements of all referenced resources, and rigorously maintaining security policies controlling which fields are editable (“allowlists”).  

How ThreatX Can Help 

ThreatX can help both identify this vulnerability and block its exploitation. Due to our attacker-centric behavioral analytics, ThreatX can flag, watch, and, if necessary, block behavior that indicates a mass assignment attack in progress.   

Watching and Blocking Mass Assignment  

It can be difficult to detect if an attacker has exploited an instance of this vulnerability because the application would show no signs of an error. However, ThreatX continuously monitors each unique client/user and would detect probing/reconnaissance activity targeting this vulnerability. Other suspicious activity, such as repeated error responses, typically indicate an attacker is up to no good. If these behaviors reached a certain risk threshold, or are observed in conjunction with other suspicious attacker behavior (which they frequently are), we would block the attacker and record the events for later review. 

Identifying Mass Assignment  

In addition, ThreatX provides visibility on potentially vulnerable API endpoints through several data points. First, the details for each attack are correlated to each endpoint targeted. Second, we compare observed requests for each endpoint against the expected usage defined in the approved API schema. Finally, failed requests are analyzed for various error conditions that indicate potential vulnerabilities.    

How Our Approach Is Unique  

Real-Time Blocking    

Some API security solutions simply highlight potential API vulnerabilities, leaving security teams to investigate and recommend code changes. Other API solutions can identify an attacking IP, but require security teams to try to model the complex behavior in a third-party WAF (or try to block one IP at a time after the fact). ThreatX doesn’t just tell you about your API vulnerabilities or attempted attacks; we also block API attacks in real-time. ThreatX proxies and scans all inbound API traffic – in real time – identifying and blocking attacks.    

ThreatX recognizes attacker behavior indicative of an attempt to exploit mass assignment, then flags and watches that user. This real-time monitoring enables ThreatX to execute advanced threat engagement techniques, such as IP interrogation, fingerprinting, and tarpitting. When a series of user interactions cross our default (or your customized) risk threshold, we block the attack.     

Step One of N…    

In many cases, attackers aren’t just going to attack with a mass assignment exploit; they’re going to string together a series of attacks over time, often using federated and sophisticated botnets. Countering this approach requires the ability to correlate attack traffic across multiple IPs, the use of advanced bot protection, and the ability to detect identifiers and techniques to associate the traffic to a unique attacker. Rather than requiring a single, significantly risky event or identifying a known signature, ThreatX analyzes behaviors from multiple vantage points. This lets the ThreatX Platform identify and block more threats, more accurately than competing API security tools.   

Less False Positives    

As risk rises, ThreatX immediately blocks an attack – stopping the threat in its tracks. ThreatX’s blocking modes are designed to block malicious requests and deter suspicious entities from attacking your APIs, while allowing benign traffic and real users through. Legacy WAFs struggle with false positives because they only make blocking decisions based on rules, but attackers and legitimate users don’t always follow the rules. Sometimes a legitimate user who forgot their password looks like an attacker, and sometimes an attacker cycling through usernames and passwords looks like a legitimate user. ThreatX can tell the difference.    

Identifying Risk    

Attackers camouflage their attempts to exploit an API with mass assignment by generating more suspicious or elevated application traffic. ThreatX detects and blocks potential threats based on behavior, but also identifies risky attributes being used in API traffic. ThreatX’s API Dashboard details API endpoint usage and how it compares to expected behavior defined by an organization’s API schema specifications. In the case of mass assignment, the ThreatX API Dashboard will detect attempts to use authorization parameters that are not part of a valid schema. With this visibility, customers can identify those back doors and shut them against these sophisticated, multi-vector attacks that are becoming a common threat.