database mass assignment

• General Solutions
• Ruby On Rails
• Jackson (JSON Object Mapper)
• GSON (JSON Object Mapper)
• JSON-Lib (JSON Object Mapper)
• Flexjson (JSON Object Mapper)
• References and future reading
• Microservices Security
• Microservices based Security Arch Doc
• Mobile Application Security
• Multifactor Authentication
• NPM Security
• Network Segmentation
• NodeJS Docker
• Nodejs Security
• OS Command Injection Defense
• PHP Configuration
• Password Storage
• Prototype Pollution Prevention
• Query Parameterization
• REST Assessment
• REST Security
• Ruby on Rails
• SAML Security
• SQL Injection Prevention
• Secrets Management
• Secure Cloud Architecture
• Secure Product Design
• Securing Cascading Style Sheets
• Server Side Request Forgery Prevention
• Session Management
• Software Supply Chain Security.md
• TLS Cipher String
• Third Party Javascript Management
• Threat Modeling
• Transaction Authorization
• Transport Layer Protection
• Transport Layer Security
• Unvalidated Redirects and Forwards
• User Privacy Protection
• Virtual Patching
• Vulnerability Disclosure
• Vulnerable Dependency Management
• Web Service Security
• XML External Entity Prevention
• XML Security
• XSS Filter Evasion

Mass Assignment Cheat Sheet ¶

Introduction ¶, definition ¶.

Software frameworks sometime allow developers to automatically bind HTTP request parameters into program code variables or objects to make using that framework easier on developers. This can sometimes cause harm.

Attackers can sometimes use this methodology to create new parameters that the developer never intended which in turn creates or overwrites new variable or objects in program code that was not intended.

This is called a Mass Assignment vulnerability.

Alternative Names ¶

Depending on the language/framework in question, this vulnerability can have several alternative names :

• Mass Assignment: Ruby on Rails, NodeJS.
• Autobinding: Spring MVC, ASP NET MVC.
• Object injection: PHP.

Example ¶

Suppose there is a form for editing a user's account information:

Here is the object that the form is binding to:

Here is the controller handling the request:

Here is the typical request:

And here is the exploit in which we set the value of the attribute isAdmin of the instance of the class User :

Exploitability ¶

This functionality becomes exploitable when:

• Attacker can guess common sensitive fields.
• Attacker has access to source code and can review the models for sensitive fields.
• AND the object with sensitive fields has an empty constructor.

GitHub case study ¶

In 2012, GitHub was hacked using mass assignment. A user was able to upload his public key to any organization and thus make any subsequent changes in their repositories. GitHub's Blog Post .

Solutions ¶

• Allow-list the bindable, non-sensitive fields.
• Block-list the non-bindable, sensitive fields.
• Use Data Transfer Objects (DTOs).

General Solutions ¶

An architectural approach is to create Data Transfer Objects and avoid binding input directly to domain objects. Only the fields that are meant to be editable by the user are included in the DTO.

Language & Framework specific solutions ¶

Spring mvc ¶, allow-listing ¶.

Take a look here for the documentation.

Block-listing ¶

Nodejs + mongoose ¶, ruby on rails ¶, django ¶, asp net ¶, php laravel + eloquent ¶, grails ¶, play ¶, jackson (json object mapper) ¶.

Take a look here and here for the documentation.

GSON (JSON Object Mapper) ¶

Take a look here and here for the document.

JSON-Lib (JSON Object Mapper) ¶

Flexjson (json object mapper) ¶, references and future reading ¶.

• Mass Assignment, Rails and You

• Browse topics

SNYK LEARN LOGIN

• 🌍 Snyk (recommended)

OTHER REGIONS

For Snyk Enterprise customers with regional contracts. More info

• 🇦🇺 Snyk AUS

Mass assignment

Be careful with parameters that are automatically bound from requests to objects, select your ecosystem, mass assignment: the basics, what are mass assignment vulnerabilities.

To make it easier to save data submitted via an HTML form into a database or object, many web application frameworks have included libraries to automatically bind HTTP request parameters (typically sent via forms) to the fields of database models or members of an object, requiring only minimal coding.

Let’s say we have a (very simple) HTML form:

When the form is submitted to the web application, it will send the form data as HTTP request parameters, and the backend code will have to read each parameter individually into a corresponding variable. Then, once all the fields have been read, the application will usually execute a database update or insert operation to save the data.

Mass Assignment makes it possible to write less code to handle this process - think about how much coding this technique could save if it was an object that had dozens of fields, and multiply this across a complex application that has many of these objects in its database.

Mass assignment vulnerabilities occur when the database model that is being assigned contains security-relevant fields, and the application user can supply values in the POST request that are saved to those fields, even though they are not present in the HTML form.

For example, if the User model contained a field isAdmin: Boolean , the user could add the POST body parameter isAdmin=true and make themselves an administrator.

For this to occur, an attacker would need to guess the names of the sensitive fields, or the source code for the vulnerable application would have to be available to the attacker (allowing them to see what sensitive fields are present in the data model).

Impacts of this attack can include bypassing authentication or authorization logic or elevation of privilege. This could then result in the destruction or disclosure of data within the application.

About this lesson

In this lesson, you will learn how mass assignment vulnerabilities work and how to protect your applications against them. We will begin by exploiting a Mass Assignment vulnerability in a simple application. Then we will analyze the vulnerable code and explore some options for remediation and prevention.

Mass assignment in the wild

In 2012, a GitHub user exploited a Mass Assignment vulnerability in GitHub’s public key update form. The flaw allowed the user to add their public key to another organization they were not a member of. The user added their key to the Ruby on Rails organization. To demonstrate proof of the exploit, the user added a file to the Rails project repository. GitHub responded, quickly fixing the vulnerability and they conducted a wide audit of their code to ensure the issue was detected and fixed if it existed anywhere else.

Mass assignment in action

New SaaS startup SuperCloudCRM recently launched their web platform designed to help businesses boost their sales and marketing efforts.

Setting the stage

SuperCloudCRM recently launched its web platform. Unfortunately, they suffered a security breach, resulting in data being leaked. What went wrong?

Mass assignment details

As mentioned, SuperCloudCRM’s developers had been logging request data for API endpoints like the POST /user/create endpoint, which creates new user accounts when a user submits the signup form.

A typical JSON payload in the request sent to the /user/create endpoint was supposed to look like this:

But a search of the /user/create endpoint’s logs for the [email protected] account around the time the user was created, found JSON POST data starting with the following excerpt:

It was different to the normal requests, and had a long request body with dozens more fields all starting with the letter r . What was the attacker doing? All of these weird field names that weren’t part of the user model schema, which was:

After doing some testing like the scenario above showed, a few things were discovered.

First, the new user account’s password was apparently being saved to the database in plaintext. Not good! But what stuck out was that the application ignored the non-existent fields and just assigned the fields that were actually part of the User model schema.

The data from the new User document was sent back to the API client and the attacker could then infer which of the list of fields starting with r were part of the User model schema, because if a field existed it was saved and echoed back in the response with the other user data.

A search of the /user/create endpoint’s request log entries around the same time revealed that thousands of similar requests had been sent. Each request testing lists of possible field names in the User model schema.

It was concluded that the attackers had brute-forced HTTP requests with various field name guesses to enumerate the organization and role fields in the schema. Despite them not being referred to anywhere in the client-side JavaScript code, the attackers were able to discover these security-related field names.

So, if the attackers knew these field names, what would they do then? Well, this could have led to a possible mass assignment attack. After hours of reviewing logs for the POST /user/create and POST /user/update endpoints the incident response team found dozens of requests had been submitted to the application, which looked similar to:

The requests appeared to be successful. Each of the requests changed the organization to a different customer, essentially giving the attackers access to each of them as admins. The last request was:

This seemed to explain why [email protected] was an administrator in the Cowmoo Industries organization.

By exploiting this mass assignment vulnerability and adding themselves as the administrator for various customers, the attackers were able to access the organizations’ data within SuperCloudCRM and steal it.

Mass assignment by different names

The concept of mass assignment is known by different names in various programming languages or frameworks. NodeJS and Ruby on Rails call it mass assignment. It is referred to as autobinding in Java Spring MVC and ASP NET MVC. PHP calls it object injection.

Mass assignment under the hood

Let’s have a look at this vulnerable application in more detail by going through the server-side code.

The schema for the User model is defined here, with the user’s credentials, email address, plus their role and organization they belong to. During signup, the credentials and email address are the only values that are supposed to be supplied by the user and accepted by the application.

Firstly, let's recap what took place in the example above.

• The User schema consisted of several fields: username, password, email, role and organization.
• Only the username, password and email fields were sent from the web browser to the /user/create endpoint
• The API endpoint used mass assignment to blindly assign any field from the POST request’s JSON data to the User model in the database (if the field existed in the User schema).
• The attackers were able to determine the names of security-related fields in the schema (role and organization)
• The attackers could supply arbitrary values for these fields when creating or updating a user account
• This let the attackers add themselves to other organizations and elevate their privileges to those of an administrator

Here ( $user = new User($request->post()); ), the endpoint creates a new User object and in doing so, passes all contents of the POST request to the constructor. PHP can “smartly” figure out which parameters go to which attributes of the class; however, this isn’t so smart when those attributes are certain things that shouldn’t be assignable! Even if the form only accepts inputs with username , password and email , a malicious actor can guess the other forms and simply add those fields to the JSON manually. As PHP has no way of discerning what it receives from “good” and “bad”, it simply updates them all. If only there were a way to tell PHP exactly which fields we don’t want to be assignable like that!

Impacts of mass assignment

By exploiting mass assignment vulnerabilities, a malicious actor could create multiple security problems including

• Data tampering : Attackers can modify sensitive information in the database, such as password or account balance
• Data theft : Attackers can gain access to confidential information stored in the database
• Elevation of privilege : Attackers can manipulate the properties of an object to gain additional privileges, such as administrator access
• Unauthorized access : Attackers can manipulate the properties of an object to gain unauthorized access to sensitive resources

Scan your code & stay secure with Snyk - for FREE!

Did you know you can use Snyk for free to verify that your code doesn't include this or other vulnerabilities?

Mass assignment mitigation

Use an allowlist of fields that can be assigned to.

Most mass assignment libraries or helper libraries should provide the ability to restrict the fields that will be read from a request and assigned to the data model. By restricting the assignment of user-supplied fields to only fields in the schema that are known safe ones, the values of security-sensitive fields will be prevented from tampering.

Using this strategy, the code for the application would be changed to add an allowlist using the pick() method of the underscore package and listing the allowed fields in the userCreateSafeFields array:

Laravel provides a library, eloquent , which, among other things, introduces object injection protection features! It gives you the ability to indicate variables that can be assigned, or otherwise, you can indicate variables that you don’t want assignable. This means that when you use mass assignment to populate a class with request data, the Laravel backend can (with your guiding hand) separate POST request input data from fields that should be populated and those that should not!

Using this strategy, the code for the application can be changed to add an allow-list of class attributes, enforcing that only these will be updated:

Use a Data Transfer Object (DTO)

Another option is to create an intermediary object (the DTO) that only has safe, assignable properties, which would be a subset of the target object that has those same fields plus any sensitive fields. Using our User example, the DTO would be:

The mass assignment operation can assign any user-supplied data to the DTO without the risk of inadvertently assigning any sensitive fields. The DTO can be copied to the final object, and during this process, any sensitive fields can be set to secure default values.

This method might require much more coding though. DTOs need to be created for all classes with sensitive fields. If there are many schemas with sensitive fields that require corresponding DTOs, then this becomes nearly as much work as not using mass assignment.

Use a denylist to declare fields that can’t be assigned to

The opposite of using an allowlist to define fields that are allowed to be assigned is to use a denylist of fields that shouldn’t be assigned. Security wisdom says to use allowlisting over denylisting because it’s safer to accidentally not include a safe field than to accidentally omit a dangerous field. So, following this advice, a denylist would be the less preferred option of the two. If there are 50 fields in a schema and only one is security-sensitive, then it is obviously much quicker to just denylist the one sensitive field. The danger here though would be if additional sensitive fields were added to the schema later and the developer forgot to add them to the denylist, then you would have a mass assignment vulnerability.

To use denylists, the code for the application would be changed in a similar manner to the code shown in the allow-list strategy shown earlier, except it would use the omit() method of the underscore package and listing the disallowed fields in the userCreateDisallowedFields array:

To use deny-lists, the code for the application would be changed in a similar manner to the code shown in the allow-list strategy shown earlier, the only difference being the User class is changed to have a “hidden” array:

Utilize a static analysis tool

Adding a static application security testing ( SAST ) tool to your devops pipeline as an additional line of defense is an excellent way to catch vulnerabilities before they make it to production. There are many, but Snyk Code is our personal favorite, as it scans in real-time, provides actionable remediation advice, and is available from your favorite IDE.

Keep learning

To learn more about mass assignment vulnerabilities, check out some other great content:

• OWASP guide to mass assignment vulnerabilties
• Find mass assignment in our top 10 list

Congratulations

You have taken your first step into learning what mass assignment is, how it works, what the impacts are, and how to protect your own applications. We hope that you will apply this knowledge to make your applications safer.

We'd really appreciate it if you could take a minute to rate how valuable this lesson was for you and provide feedback to help us improve! Also, make sure to check out our lessons on other common vulnerabilities.

What is mass assignment?

Mass assignment is a type of security vulnerability that occurs when an application code allows user-provided data to be used to set properties on an object without verifying that the user has the right to do so.

What to learn next?

Insecure default variable initialization, uncaught exception, insufficient encapsulation.

Mass Assignment

Introduction.

Software frameworks sometime allow developers to automatically bind HTTP request parameters into program code variables or objects to make using that framework easier on developers. This can sometimes cause harm.

Attackers can sometimes use this methodology to create new parameters that the developer never intended which in turn creates or overwrites new variable or objects in program code that was not intended.

This is called a Mass Assignment vulnerability.

Alternative Names

Depending on the language/framework in question, this vulnerability can have several alternative names :

• Mass Assignment: Ruby on Rails, NodeJS.
• Autobinding: Spring MVC, ASP NET MVC.
• Object injection: PHP.

Suppose there is a form for editing a user's account information:

Here is the object that the form is binding to:

Here is the controller handling the request:

Here is the typical request:

And here is the exploit in which we set the value of the attribute isAdmin of the instance of the class User :

Exploitability

This functionality becomes exploitable when:

• Attacker can guess common sensitive fields.
• Attacker has access to source code and can review the models for sensitive fields.
• AND the object with sensitive fields has an empty constructor.

GitHub case study

In 2012, GitHub was hacked using mass assignment. A user was able to upload his public key to any organization and thus make any subsequent changes in their repositories. GitHub's Blog Post .

• Whitelist the bindable, non-sensitive fields.
• Blacklist the non-bindable, sensitive fields.
• Use Data Transfer Objects (DTOs).

General Solutions

An architectural approach is to create Data Transfer Objects and avoid binding input directly to domain objects. Only the fields that are meant to be editable by the user are included in the DTO.

Language & Framework specific solutions

Whitelisting.

Take a look here for the documentation.

Blacklisting

Nodejs + mongoose, ruby on rails, php laravel + eloquent, jackson (json object mapper).

Take a look here and here for the documentation.

GSON (JSON Object Mapper)

Take a look here and here for the document.

JSON-Lib (JSON Object Mapper)

Flexjson (json object mapper), references and future reading.

• Mass Assignment, Rails and You

Authors and Primary Editors

Abashkin Anton - [email protected]

results matching " "

No results matching " ".

Point of Contact

• Vulnerability 101

Mass Assignment Vulnerability: Understanding & Mitigating the Risks in API

Mass assignment vulnerability is a critical security concern that often goes unnoticed in API development. Understanding the risks associated with this vulnerability is crucial for protecting sensitive user data. In this article, we will delve into the details of mass assignment vulnerabilities and explore effective mitigation strategies.

Introduction:

The "Mass Assignment" vulnerability is a security flaw that occurs when an application assigns user input directly to model attributes without proper validation or sanitization. This can lead to unauthorized access and modification of sensitive data, potentially compromising the security of the application and its users.

Addressing the "Mass Assignment" vulnerability is crucial for developers as it can have serious consequences, including data breaches, unauthorized access, and legal implications. Understanding and mitigating this vulnerability is essential to ensure the integrity and security of an application.

Understanding the "Mass Assignment" Vulnerability:

The "Mass Assignment" vulnerability occurs when an attacker is able to manipulate the values of model attributes by submitting unexpected or malicious data. This can happen when developers use frameworks or libraries that automatically map user input to object properties without proper validation or filtering.

Common scenarios where developers may unintentionally introduce the "Mass Assignment" vulnerability include:

• Using frameworks or libraries that provide automatic mapping of user input to object properties without considering the security implications.
• Allowing users to submit data that directly maps to sensitive attributes without proper validation.
• Failing to implement proper input validation and sanitization techniques.

The impact of the "Mass Assignment" vulnerability can be severe. Attackers can exploit this vulnerability to gain unauthorized access to sensitive data, modify user privileges, or even execute arbitrary code on the server. This can lead to data breaches, compromised user accounts, and potential legal issues.

Common Examples of "Mass Assignment":

There are several common examples of the "Mass Assignment" vulnerability. Let's explore a few of them:

User Profile Update: Suppose an application allows users to update their profile information, including their email address and password. If the application blindly maps user input to the corresponding model attributes without proper validation, an attacker can manipulate the request to update other sensitive fields such as admin privileges.

Role-Based Access Control: In applications with role-based access control, developers often use a single parameter to assign roles to users. If this parameter is not properly validated, an attacker can modify it to gain unauthorized access to sensitive functionality or elevate their privileges.

API Endpoints: APIs that accept JSON or XML payloads are also susceptible to the "Mass Assignment" vulnerability. If the API endpoint maps the incoming request directly to model attributes without proper validation, an attacker can manipulate the payload to modify sensitive data or gain unauthorized access.

These examples highlight the importance of implementing proper validation and sanitization techniques to mitigate the risks associated with the "Mass Assignment" vulnerability.

Risks and Consequences:

The "Mass Assignment" vulnerability poses significant risks and consequences for both developers and users. Some of the potential risks and consequences include:

Data Breaches: Exploiting the "Mass Assignment" vulnerability can lead to unauthorized access to sensitive data, including personal information, financial records, and confidential business data. This can result in serious privacy breaches and financial losses.

Unauthorized Access and Privilege Escalation: Attackers can manipulate the values of model attributes to gain unauthorized access to restricted functionality or elevate their privileges within the application. This can lead to unauthorized actions, such as modifying critical settings, accessing sensitive data, or impersonating other users.

Reputation Damage: Security breaches resulting from the "Mass Assignment" vulnerability can severely damage the reputation of the application and its developers. Users lose trust in the application's ability to protect their data, leading to a loss of user base and potential legal consequences.

Legal Implications: Depending on the nature of the application and the data involved, security breaches resulting from the "Mass Assignment" vulnerability can have legal implications. Developers may face legal actions, regulatory fines, and potential lawsuits for failing to protect user data adequately.

Real-world examples of security breaches resulting from the "Mass Assignment" vulnerability include the 2012 GitHub incident, where an attacker exploited the vulnerability to gain administrative access to repositories. This incident highlighted the severity and impact of this vulnerability.

Best Practices for Mitigating the "Mass Assignment" Vulnerability:

To mitigate the risks associated with the "Mass Assignment" vulnerability, developers should follow these best practices:

Whitelist Input Validation: Developers should implement strong input validation techniques to ensure that only expected and valid data is accepted. This includes whitelisting allowed attributes and rejecting any unexpected or malicious input.

Use Role-Based Access Control (RBAC): Implement RBAC to control user privileges and access to sensitive functionality. Do not rely solely on user input to determine roles and permissions.

Implement Attribute-Level Access Controls: Instead of blindly mapping all user input to corresponding attributes, developers should implement attribute-level access controls. This ensures that only authorized users can modify specific attributes.

Sanitize and Filter User Input: Before assigning user input to model attributes, developers should sanitize and filter the data to remove any potential malicious content. This includes validating data types, length restrictions, and ensuring data integrity.

Implement Secure Coding Practices: Follow secure coding practices, such as avoiding dynamic attribute assignment, using strong encryption for sensitive data, and regularly updating frameworks and libraries to their latest secure versions.

Regular Security Testing and Auditing: Conduct regular security testing and auditing of the application to identify and mitigate any vulnerabilities, including the "Mass Assignment" vulnerability. This includes penetration testing, code review, and vulnerability scanning.

Tools and Resources:

To aid developers in addressing the "Mass Assignment" vulnerability, the following tools, libraries, and resources can be helpful:

OWASP Cheat Sheet - Mass Assignment: The OWASP Cheat Sheet provides guidelines and recommendations for securing web applications against the "Mass Assignment" vulnerability. It offers practical advice and code snippets for developers to implement secure coding practices.

Security-Focused Libraries and Frameworks: Many programming languages and frameworks provide security-focused libraries and modules that can help mitigate the "Mass Assignment" vulnerability. Examples include Django's ModelForm, Laravel's Mass Assignment Protection, and Ruby on Rails' Strong Parameters.

Platform-Specific Security Guidelines: Developers should refer to platform-specific security guidelines and resources provided by the framework or platform they are using. These guidelines often include best practices and recommendations for securing applications against common vulnerabilities, including "Mass Assignment."

Code Review and Testing Tools: Developers should leverage code review and testing tools to identify and mitigate the "Mass Assignment" vulnerability. Tools like SonarQube, OWASP ZAP, and Burp Suite can help identify security flaws in the code and test the application for vulnerabilities.

The Role of Security Testing and Auditing:

Regular security testing and auditing play a crucial role in identifying and mitigating the "Mass Assignment" vulnerability. Various testing techniques can be employed, including:

Penetration Testing: Conducting penetration tests can help identify vulnerabilities and potential attack vectors, including the "Mass Assignment" vulnerability. Ethical hackers simulate real-world attacks to identify security weaknesses and provide recommendations for improvement.

Code Review: Manual code review or automated tools can help identify insecure coding practices, including instances of the "Mass Assignment" vulnerability. Developers should review their code regularly and ensure it follows best practices for secure coding.

Vulnerability Scanning: Automated vulnerability scanning tools can scan the application for known vulnerabilities, including the "Mass Assignment" vulnerability. These tools can help identify potential weaknesses and provide guidance on how to address them.

By employing these testing techniques, developers can proactively identify and mitigate the "Mass Assignment" vulnerability, ensuring the security and integrity of their applications.

Conclusion:

Addressing the "Mass Assignment" vulnerability is crucial for developers to protect the integrity and security of their applications. By understanding the definition, risks, and consequences of the vulnerability, developers can take proactive measures to mitigate its impact.

Implementing best practices, such as whitelisting input validation, utilizing role-based access control, and regular security testing and auditing, can significantly reduce the risks associated with the "Mass Assignment" vulnerability.

Need Help? Hire us part-time

Hire a dedicated, part-time security consultant with over 10+ years of experience to work closely with your dev/security team. you only pay for the time you need, with no long-term contracts. learn more.

Secured High Growth Companies Worldwide

Let's find out if we are a good fit with a 30-min intro call

Plans start from $1,000. No Contracts, Cancel Anytime.

Mass Assignment Vulnerability: How It Works & 6 Defensive Measures

What Is a Mass Assignment Vulnerability? 

Mass assignment vulnerabilities occur when an application automatically assigns user input to model properties without proper filtering or validation. This allows attackers to modify object properties they shouldn't be able to access, such as changing a user's permissions, email, or password.

These vulnerabilities often occur in applications that use frameworks allowing mass assignment from request parameters. Without strict controls, attackers can supply unexpected parameters through common methods like POST requests, leading to unauthorized changes in the application's data.

This is part of a series of articles about application security.

In this article:

The Impact of a Mass Assignment Vulnerability

How mass assignment vulnerabilities work .

• Example of a Mass Assignment Attack
• 1. Allowlist Allowed Attributes ‍
• 2. Sanitize and Validate Input ‍
• 3. Keep Dependencies Up-to-Date ‍
• 4. Employ Strong Authentication and Authorization ‍

5. Use Role-Based Access Control (RBAC)

The impact can be severe, depending on the data an attacker can modify. It might lead to privilege escalation, data leakage, or full account takeover. This could result in significant financial losses, legal penalties, or damage to an organization's reputation.

By exploiting mass assignment vulnerabilities, attackers can bypass usual access controls, altering critical system settings or user data without detection. The scale of the attack often hinges on the application's data sensitivity and what the altered parameters control.

Mass assignment vulnerabilities exploit how frameworks handle user input. When an application doesn’t differentiate between which parameters should and shouldn’t be modified directly by a user, it opens up a vector for attack. Once such a weak point is identified, the attacker crafts malicious HTTP requests that include parameters targeting these unprotected attributes.

For example, consider a scenario where an application uses an object to store user profile information. The attacker can send a POST request with additional, unanticipated parameters such as role=admin or status=disabled. If these parameters are not explicitly filtered out or validated against an allowlist, the application's backend logic might accept these as legitimate and alter the user object’s properties accordingly. 

Thus, attackers can gain elevated privileges or disrupt services by manipulating key object attributes through seemingly innocuous user input. These attacks are made possible by the common practice of binding form or API input directly to data models. Without rigorous checks and balances, such as field-level validation, attackers can easily insert unauthorized data into these models. 

This is particularly dangerous when combined with other vulnerabilities or weak points within the application, such as insecure direct object references or insufficient logging and monitoring, which can mask or facilitate unauthorized access and modifications.

Example of a Mass Assignment Attack 

This example was adapted from the official OWASP cheat sheet . Let’s look at a scenario where a mass assignment vulnerability exists in a basic web application designed for editing user account information.  ‍

The application comprises a straightforward HTML form that captures a user's ID, password, and email address. This form interacts with a backend controller upon submission, binding user input to a corresponding User object.

The form is outlined as follows:

The User object, meant to receive the form data, looks like this:

The server-side handling of the form submission is managed by a controller mapped to /addUser and designed to process POST requests. Upon receiving a form submission, it invokes a service method to add the user data to the system:

A typical, legitimate request to this endpoint might look like this:

However, exploiting the mass assignment vulnerability involves manipulating the request to include an isAdmin parameter, which is not intended to be modified directly by end users through the form. By appending &isAdmin=true to the request, an attacker can alter the isAdmin property of the User object, granting themselves administrative privileges:

This exploit demonstrates the risk associated with indiscriminately binding user input to model attributes, especially when sensitive properties like isAdmin are involved. Without adequate filtering or validation, this vulnerability can compromise the integrity of the application.

6 Ways to Mitigate the Security Risks of Mass Assignment 

Here are some of the measures that can be used to prevent mass assignment attacks.

1. Allowlist Allowed Attributes

Define which attributes can be safely exposed to mass assignment. Using an allowlist approach ensures only specified attributes can be updated through user input.

This method requires explicitly listing allowed parameters, making unintended data modifications less likely. Regularly review and update the allowlist to accommodate changes in the application’s functionality.

2. Sanitize and Validate Input

Sanitizing input involves stripping harmful data before it’s processed, whereas validation ensures the data meets specific criteria. Together, they can prevent attackers from submitting malicious or unexpected data through mass assignment.

Input should be sanitized to remove potential executable code or SQL commands. Validation rules, like checking for allowable values or correct data types, further reduce the risk of unauthorized modifications.

3. Keep Dependencies Up-to-Date

Applications often rely on external libraries or frameworks that might contain vulnerabilities, including those leading to mass assignment issues. Regularly update these dependencies to ensure that known vulnerabilities are patched.

Subscribe to notifications from dependency providers and security bulletins to stay informed about relevant security updates. Automated tools can help identify outdated dependencies in a project, simplifying the update process.

4. Employ Strong Authentication and Authorization

Authentication mechanisms ensure that users are who they claim to be, while authorization checks confirm they have permission for the requested actions. Ensuring both are in place can significantly reduce the risk of mass assignment vulnerabilities being exploited. ‍

Authorization checks should occur at every stage of data processing, especially before sensitive operations like data updates. This prevents unauthorized users from exploiting mass assignment vulnerabilities to access or modify data.

RBAC ensures users can only interact with data and actions appropriate for their role. This helps mitigate risks by limiting what authenticated users can modify, even if a mass assignment vulnerability exists.

RBAC requires defining roles and permissions carefully, ensuring they align with the principle of least privilege. This means users get only the access necessary for their role, reducing the potential impact of a mass assignment vulnerability.

6. Monitor and Log Activities

Monitoring and logging access and modification of sensitive data help detect unauthorized attempts to exploit mass assignment vulnerabilities. Automated alerts can notify administrators of suspicious activities, enabling rapid response to potential breaches.

Logs should capture sufficient detail to understand the nature of each attempt, including who made the request and what was attempted. Regular analysis of logs can also help identify patterns indicating unaddressed vulnerabilities.

API Security with Pynt

Pynt is an innovative API Security Testing platform exposing verified API threats through simulated attacks. We help hundreds of companies such as Telefonica, Sage, Halodoc, and more, to continuously monitor, classify and attack poorly secured APIs, before hackers do. 

Pynt's leverages an integrated shift-left approach, and unique hack technology using home-grown attack scenarios, to detect real threats, discover APIs, suggest fixes to verified vulnerabilities, thereby eliminating the API attack surface risk.

Thousands of companies rely on Pynt to secure the no. 1 attack surface - APIs, as part of their AppSec strategy. 

Learn more about Pynt and get started free

Want to learn more about Pynt’s secret sauce?

See our Fast Start promotion and start your first pentest on The Cobalt Offensive Security Testing Platform for only $4,950.

• Application Pentest
• Secure Code Review
• LLM Pentest
• Network Pentest
• Red Teaming
• Digital Risk Assessment
• Social Engineering
• Device Hardening
• IoT Testing

• get started

Mass Assignment & APIs - Exploitation in the Wild

The APIs (Application Programmable Interfaces) are widely used to power applications, and one of the popular choices for implementing API is  REST APIs . With this increase in popularity and usage, many security risks also come into the picture. 

APIs have their own  OWASP API Top 10  list, which describes the vulnerabilities commonly found in the APIs, including Mass Assignment. 

This blog will dive deeply into understanding and exploiting mass assignment vulnerabilities. 

Mass Assignment - A 20ft Overview: 

Modern frameworks allow developers a convenient mass assignment functionality that lets developers directly take a “user-supplied Key-Value Pair” input to the object database. This reduces the requirement of writing code for such custom Key-Value pairs and increases the development efficiency but at the cost of security risks if not implemented correctly. 

A mass assignment without a whitelist of allowed “Key-Value Pairs” could allow an attacker to use arbitrary values to create or update the resources abusing the applications’ regular workflow. Privilege escalation is one of the most common vulnerabilities arising from Mass Assignment vulnerability. 

According to OWASPthis  vulnerability  depends on the language/framework in question can have several alternative names:

Mass Assignment: Ruby on Rails, NodeJS.

Autobinding: Spring MVC, ASP NET MVC.

Object injection: PHP.

For example, consider an API that allows users to update their profile information. The API may accept a JSON payload that contains multiple fields such as name, email, and address. Without proper validation, an attacker can add additional fields such as "isAdmin":true” or "isSuperUser":true and gain elevated privileges as an admin or superuser. 

Let’s understand this attack further with the help of a vulnerable code snippet as described below: 

const express = require('express');

const app = express();

app.post('/users', (req, res) => {

  const newUser = {

    username: req.body.username,

    password: req.body.password,

    isAdmin: req.body.isAdmin

  };

  // Save new user to database

app.listen(3000, () => {

  console.log('Server started on port 3000');

In the above code, the “newUser” object is created from the request body without validation or filtering. An attacker can attempt to craft a request with an additional field named “isAdmin”:true and send it to the server to escalate the privileges. 

To remotely exploit this issue, an attacker can send a POST request with an additional "isAdmin" field set to "true" to register as an administrator. In this case, isAdmin is an optional body parameter.

POST /users HTTP/1.1

Host: example.com

Content-Type: application/json

  "username": "attacker",

  "password": "password",

  "isAdmin": true

Now, to mitigate this issue, simply adding a check to ensure that only the user with an admin session can trigger this parameter will fix the underlying vulnerability as described in below code: 

Const port = 3000;

    password: req.body.password

if (req.user.isAdmin && req.body.isAdmin) {

  // Only admins can set isAdmin field

  newUser.isAdmin = req.body.isAdmin;

app.listen(port, () => {

  console.log(`Server started on port {port}`);

Hunting for Mass Assignment Attack in the Wild - A Practical Approach

Mass Assignment is not necessarily to be found in the user profile to perform privilege escalations. You can find it on any API endpoint, which could be using a parameter of interest to the attacker, causing significant damage to the application and its user’s reputation. 

Note: Always read the API documentation to understand and identify interesting parameters/key-value pairs that could cause significant impact.

Let’s understand how to approach the Mass Assignment Attack in a black-box/grey-box assessment with the help of the “crAPI” Demo Lab. 

Locally set up the  crAPI demo lab .

Navigate to the shop -  http://127.0.0.1:8888/shop

Note that the Available Balance by default is $100, and now Buy any item while capturing the request in Burp Suite or another proxy tool. 

Send the Request to the repeater for later use.

Observe after purchasing the items; Available Balance is changed. 

In the repeater tab, modify the request by changing the request method to  GET  and adding “/all” route to retrieve the information of all orders.

Observe that the application has returned all information about past orders.

Modify the request, and change the “all” to any random order ID. 

Send the request, and observe the methods allowed and the order status.

Again, modify the request by changing the request method to  PUT  and adding the status as a return.

Send the request and observe the error message in the response.

Send the request again by adding the status as returned and observing that the order status has changed to returned.

Navigate to the shop, and observe that credit transfers to the account.

In the above lab scenario, as an attacker, it was possible to mark a delivered item as returned to get the cashback allowing an attacker to financially abuse the application with the help of a mass assignment attack. 

Since now you know what chaos this attack can bring to the organization from the user integrity and the financial aspects, it is essential to understand how to implement a fix to prevent such attacks. 

Fixing Mass Assignment - Remediation Approach 

Some common ways to fix mass assignment issues include:

• Disable Automatic Property Mapping: Ensure that your applications have the automatic mapping disabled and always map the properties manually.
• Read-Only Key-Value Pairs: Ensure to set the fields retrieved from the “request body” that is not present in the “request body” should be read-only, and a user should not be allowed to tamper them.

You can find a detailed remediation guide  here .

References and Further Reads

https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html

https://www.impart.security/post/mass-assignment-101

https://crashtest-security.com/api-mass-assignment/

https://www.wallarm.com/what/mass-assignment

About Harsh Bothra

Related resources.

Secure Software Best Practices: Protect Against Server-Side Request Forgery

Secure Software Best Practices: Validate User Input

Source Code Review

Never miss a story.

• schedule a demo
• Cobalt Platform
• Offensive Security
• Application Security
• Network Security
• Cloud Security
• Brand Protection
• Device Security
• Core Community
• Product Documentation
• Resource Library
• Events & Webinars
• Vulnerability Wiki
• Trust Center

This is a title

• © 2024 Cobalt
• Terms of use
• Your privacy settings
• Do not sell my data

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

0xa6-mass-assignment.md

Latest commit, file metadata and controls, api6:2019 - mass assignment.

Is the API Vulnerable?

Objects in modern applications might contain many properties. Some of these properties should be updated directly by the client (e.g., user.first_name or user.address ) and some of them should not (e.g., user.is_vip flag).

An API endpoint is vulnerable if it automatically converts client parameters into internal object properties, without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update object properties that they should not have access to.

Examples for sensitive properties:

• Permission-related properties : user.is_admin , user.is_vip should only be set by admins.
• Process-dependent properties : user.cash should only be set internally after payment verification.
• Internal properties : article.created_time should only be set internally by the application.

Example Attack Scenarios

Scenario #1.

A ride sharing application provides a user the option to edit basic information for their profile. During this process, an API call is sent to PUT /api/v1/users/me with the following legitimate JSON object:

The request GET /api/v1/users/me includes an additional credit_balance property:

The attacker replays the first request with the following payload:

Since the endpoint is vulnerable to mass assignment, the attacker receives credits without paying.

Scenario #2

A video sharing portal allows users to upload content and download content in different formats. An attacker who explores the API found that the endpoint GET /api/v1/videos/{video_id}/meta_data returns a JSON object with the video’s properties. One of the properties is "mp4_conversion_params":"-v codec h264" , which indicates that the application uses a shell command to convert the video.

The attacker also found the endpoint POST /api/v1/videos/new is vulnerable to mass assignment and allows the client to set any property of the video object. The attacker sets a malicious value as follows: "mp4_conversion_params":"-v codec h264 && format C:/" . This value will cause a shell command injection once the attacker downloads the video as MP4.

How To Prevent

• If possible, avoid using functions that automatically bind a client’s input into code variables or internal objects.
• Whitelist only the properties that should be updated by the client.
• Use built-in features to blacklist properties that should not be accessed by clients.
• If applicable, explicitly define and enforce schemas for the input data payloads.
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

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.

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

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. 

Learn why an attacker-centric approach is critical when detecting and preventing threats from exploiting vulnerabilities with mass assignment:   Why an Attacker-Centric Approach Is Key to API Protection .

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.    

Get started protecting your APIs against mass assignment by requesting a 1:1 demo  of the ThreatX solution.

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. 

Learn more about the OWASP API Top 10:

• Broken user authentication
• Excessive data exposure
• Lack of resources and rate limiting
• Broken functional-level authorization

About the Author

Bret settle.

Bret has served in multiple executive roles for Corporate Express/Staples and BMC Software and has extensive knowledge of the software development and security products industries. Bret has been responsible for enterprise security in multiple roles and has been an innovator throughout his career and has a proven track record of building and developing high performing organizations and dynamic cyber security teams.

Subscribe for updates

Sign up for exclusive API and application threat research, guidance, and strategy.

Related Content

Threatx security xchange: jeff gardner, ciso , why i joined threatx, q3 threatx platform data: spotlight on the banking industry, join our newsletter.

What is Mass Assignment? Attacks and Security Tips

What is a mass assignment vulnerability.

To make things easier for developers, many frameworks include features that automatically associate the parameters of an HTTP request with variables linked to an object in the application code.

A Mass Assignment vulnerability occurs when the server does not correctly filter the data transmitted by the user and associates it directly with an object without verification.

In this way, an attacker can add new parameters to the HTTP request, which will create or replace variables in the application code although this was not initially intended.

Depending on the framework, these are also known as “autobinding” or “object injection” vulnerabilities.

Impact of a Mass Assignment vulnerability

The main impact of a Mass Assignment vulnerability is linked to modifying or creating variables. Depending on the variables or objects affected, the impact can be more or less significant, ranging from the simple modification of a value with no impact to a privilege escalation.

Indeed, when the vulnerability is present in a feature linked to the creation or modification of users, it is not uncommon to be able to escalate privileges.

This was the case, for example, on the Github platform in 2012, when a Mass Assignment vulnerability enabled users to upload their SSH public key to any organisation, potentially resulting in a massive data leak.

Such a vulnerability is not to be taken lightly, as it can have a severe impact.

How to identify this type of vulnerability?

As an attacker or pentester does not necessarily have a list of all the variables and values associated with the modified object on the server side, identifying a Mass Assignment vulnerability can be complex.

Depending on the technical conditions of the pentest, here are a few ways of identifying this type of security flaw:

• In white box, i.e. with access to the source code, it is possible to refer to the data models to identify sensitive fields that would not be transmitted by default in HTTP requests.
• Without access to the source code, this is more complex. One technique is to test known or probable parameters. This involves fuzzing the parameters. For example, adding a “role” field to the user creation request with standard values such as “admin” or “root” can lead to a privilege escalation in the event of Mass Assignment.
• In some cases, using the API documentation, it is possible to identify parameters that are not used by default. For example, with access to the introspection of a GraphQL API, i.e. to the list of fields associated with an entity, it is possible to try to add a variable in certain queries or mutations in the hope that this will be taken into account.
• Another technique is to observe the server responses. If additional fields are returned, it may be useful to reuse them in requests to detect Mass Assignment. Let’s imagine, for example, that we have access to the list of users. If you access the API route used to list users, you can see a “role” field associated with each user in the server response. It may therefore be useful to add this role parameter with a valid value in the request used to modify the profile information or the request used to create a user.

What are the common exploits of Mass Assignment vulnerabilities?

Mass assignment and privilege escalation.

During a grey box pentest , we had access to an application with several levels of user privileges. We had a user access (not admin), but which nevertheless allowed us to create other users with the same level of privileges.

Using the graphic interface, the request to add a user looked like this:

The content of the server response in JSON was as follows:

As we can see, a “Profiles” field is returned in the JSON object corresponding to the new user we have just created. It seems to correspond to the user’s rights. This field has been added automatically. In particular, we can see that the newly created user has a profile of type “customer” associated with ID 5. This profile has certain roles.

The fact that this “Profiles” field is present in the response even though it was not initially filled in should immediately alert us. We can now try to replay the creation of a user by adding a “Profiles” field.

Here, we know that profile ID 5 corresponds to a “customer” type user. Let’s try this with ID 1. We’ve left the other fields empty because we didn’t know the existing values:

Server response:

The Mass Assignment attack has been taken into account. The profile ID “1” has been associated with the user we have just created. The response tells us that we have successfully created an administrator type user.

This means that on the server side, the entire JSON object sent by the attacker is used to link the transmitted fields to the user object created. This is done without checking what data is being transmitted and by accepting an unexpected field.

We can now connect with the new user. Our privileges have been escalated and we can perform all the actions restricted to administrators.

Mass Assignment on a GraphQL API and privilege escalation

During a pentest on an application running with a GraphQL API, a mutation was used to update the user’s profile. By default and using the graphical interface, the mutation transmitted was as follows:

At first glance, there’s nothing particularly interesting about this mutation. It allows a user to change his/her surname, first name and telephone number.

However, we had access to GraphQL introspection (the equivalent of the documentation for a classic API) and we were able to see that the GraphQL “User” object also had a “role” field.

By modifying the previous mutation, we were able to change the role of our user due to a Mass Assignment. This enabled us to escalate our privileges:

Full request:

Following this request, our user became an administrator because the mutation took into account the role field even though it was not sent by default.

How to prevent Mass Assignment vulnerabilities?

Fortunately, preventing or correcting this type of vulnerability is fairly straightforward.

It involves setting up a white list of fields that are authorised to be used on the server side to create or modify an object. In addition, only non-sensitive fields should be authorised. And if other fields are present in the request received, they must not be taken into account by the server.

Frameworks often allow this type of whitelist to be configured simply. A list of potential existing solutions by framework can be found on the OWASP website.

If we go back to the previous examples, in the first case, the white list must not include the “profiles” field. If a user tries to send a value for this field, the value transmitted should not be taken into account when creating the user.

In the second case, the mutation used to modify the profile must not accept the “role” value. It must be limited to the “first_name”, “last_name” and “language” parameters only.

Author : Yoan MONTOYA – Pentester @Vaadata

Related Posts

What is rfi remote file inclusion exploitations and security tips, introduction to nuclei, an open source vulnerability scanner, what is prototype pollution exploitations and security tips.

Mass Assignment

Description.

Mass Assignment is a vulnerability wherein an active record pattern is manipulated into modifying data items that should normally restrict user functions such as passwords, granted permissions, or admin access. They arise when objects on the backend e.g. database records, are created by using the object representation received with the client request including fields that are not intended to be freely altered.

Active record and object-relational mapping are common features in many web application frameworks as they allow for serialized external data to be automatically converted upon input into internal objects and, subsequently, into the database records field. Depending on the framework, developers are sometimes allowed to automatically bind HTTP request parameters into program code variables or objects for ease of use. However, if the conversion interface for the framework is overly permissive and developers haven’t marked specific fields as immutable, the potential for exploitation is open.

Malicious attackers can leverage Mass Assignment vulnerabilities to manipulate the internal state of the application and potentially compromise its confidentiality, integrity, and availability. By overwriting the value of certain fields, an attacker may be able to modify an admin permission flag, thus effecting an authorization bypass which, depending on the level of authorization, could lead to full server access.

In 2012, none other than Github, the world’s code repository, was shown to be harbouring a potentially catastrophic Mass Assignment vulnerability that ended up being exposed by a security researcher in a fairly public stoush. The issue was fortunately resolved with no loss of data; but the security researcher in question was able to upload his public key to any organisation and thus potentially make malicious changes in their repositories.

The following exemplifies a Mass Assignment attack within a web application that stores users in a NoSQL database and implements access control by simply keeping one boolean flag is_admin for each user.

Upon sign up, some fields need to be used to create the new user. If the web application uses the whole POST data to build a new User object, a malicious actor could add the is_admin=1 field to the post data to overwrite the default value and gain administrative privileges on the application.

Developers must avoid using functions that bind client input into variables or internal objects automatically. Additionally, developers must explicitly define all payloads and parameters that the server is expecting.

Depending on the application framework, it may be possible to only allow fields that are determined safe to be fetched from the client request. If the application does not allow for this process, developers must ensure they manually determine which fields are allowed to be extracted from the request and used in downstream contexts.

Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar.

• OWASP ASVS : 5.1.2
• OWASP Testing Guide : Test Business Logic Data Validation , Test Ability to Forge Requests , Test Integrity Checks

Table of contents

• Mass Assignment in .NET
• Mass Assignment in Java
• Mass Assignment in NodeJS
• Mass Assignment in PHP
• Mass Assignment in Python
• Mass Assignment in Ruby

• Cloud login

OWASP API security – 6: Mass assignment

Publish on 27 May, 2022 - by Justin Fletcher Last updated: 27 Dec, 2023 --> Last updated: 27 Dec, 2023

Introduction

1: Broken object level authorisation

2: Broken user authentication

3: Excessive data exposure

4: Lack of resources & rate limiting

5: Broken function level Authorization

6: Mass assignment

7: Security misconfiguration

8: Injection

9: Improper assets management

10: Insufficient logging & monitoring

The mass assignment vulnerability is a lack of data input validation that allows an attacker to modify data or elevate privileges by manipulating payload data.  In the case of an object database, for example, if the payload maps directly to the stored data and is inserted directly, without input validation compared against authorisation levels, then the attacker can craft a payload that alters data not intended to be altered.

To prevent against mass assignment APIs need to validate input against a blacklist or preferably a whitelist so that only the expected fields of the payload are evaluated, coupled with authorisation validation to ensure the client has the correct privileges on those fields.  This ensures that data can only be modified by a client that is granted the rights to modify that data.

OWASP summary

Source: OWASP mass assignment

APIM context

While, in general, mass assignment is an API issue to solve an APIM can facilitate the process.  Validation of the payload through, for example, a JSON schema ensures that the payload contains only the expected fields.

Additionally an APIM can validate authentication and authorisation by scope.  This ensures that the client has the correct credentials before the API processes the request.

Tyk vs Apollo

Powerful security

Do you always want to redeploy the whole stack if you change a security policy? What if you need the flexibility to expose the same API to different groups of users? How do you model this with a single annotated schema?

Tyk approach

Payload validation can be implemented in various ways with the Tyk APIM.

• JSON schema validation to ensure the payload meets the defined schema, and rejects payloads that do not.
• Body transformation allows using string template syntax, which is a powerful tool for generating the desired output from the input.
• Custom plugins for more complex cases or logic not satisfied by the first 2, users can write custom plugins in a variety of languages, either directly or through gRPC calls, to implement their requirements.
• Request method transformation while not directly a Mass Assignment prevention, it is a feature that can help ensure that APIs are called with the correct methods.

In addition to the technical solutions mentioned above, Tyk also recommends considering splitting Admin APIs from client facing APIs. By having the admin usage of APIs separate from client facing APIs then different policies, payload validation methods, authentication and authorisation checks in the APIM can be separated and managed under different governance models providing a clear split between the roles.

API Market & Industry Research API platform governance & optimisation Create, secure & test APIs Monitor, troubleshoot & update APIs

Share with your network

Privacy Overview

Burp Scanner

Burp Suite's web vulnerability scanner

Product comparison

What's the difference between Pro and Enterprise Edition?

Download the latest version of Burp Suite.

• Web Security Academy
• API testing

Lab: Exploiting a mass assignment vulnerability

PRACTITIONER

To solve the lab, find and exploit a mass assignment vulnerability to buy a Lightweight l33t Leather Jacket . You can log in to your own account using the following credentials: wiener:peter .

Required knowledge

To solve this lab, you'll need to know:

• What mass assignment is.
• Why mass assignment may result in hidden parameters.
• How to identify hidden parameters.
• How to exploit mass assignment vulnerabilities.

These points are covered in our API Testing Academy topic.

Launching labs may take some time, please hold on while we build your environment.

In Burp's browser, log in to the application using the credentials wiener:peter .

Click on the Lightweight "l33t" Leather Jacket product and add it to your basket.

Go to your basket and click Place order . Notice that you don't have enough credit for the purchase.

In Proxy > HTTP history , notice both the GET and POST API requests for /api/checkout .

Notice that the response to the GET request contains the same JSON structure as the POST request. Observe that the JSON structure in the GET response includes a chosen_discount parameter, which is not present in the POST request.

Right-click the POST /api/checkout request and select Send to Repeater .

In Repeater, add the chosen_discount parameter to the request. The JSON should look like the following:

{ "chosen_discount":{ "percentage":0 }, "chosen_products":[ { "product_id":"1", "quantity":1 } ] }

Send the request. Notice that adding the chosen_discount parameter doesn't cause an error.

Change the chosen_discount value to the string "x" , then send the request. Observe that this results in an error message as the parameter value isn't a number. This may indicate that the user input is being processed.

Change the chosen_discount percentage to 100 , then send the request to solve the lab.

Community solutions

Register for free to track your learning progress

Practise exploiting vulnerabilities on realistic targets.

Record your progression from Apprentice to Expert.

See where you rank in our Hall of Fame.

Already got an account? Login here

Test APIs for vulnerabilities using Burp Suite

• Mass Assignment

What is a Mass Assignment Attack?

In order to reduce the work for developers, many frameworks provide convenient mass-assignment functionality. This lets developers inject an entire set of user-entered data from a form directly into an object or database. Without it, developers would be forced to tediously add code specifically for each field of data, cluttering the code base with repeated form mapping code.

The downside of this functionality is that it is often implemented without a whitelist that prevents users from assigning data to protected fields. An attacker may exploit this vulnerability to gain access to sensitive data or to cause data loss.

As demonstrated by prominent cases , even the best teams of developers can miss this non-obvious vulnerability.

An Example of a Vulnerability

In this example, a web shop allows users to sign up and keep track of their orders. The owner of the web shop has a special administrator account that allows them to manage other users and their orders. The administrator account is created in the database, just like a regular user account, except it has an is_administrator flag set.

On the sign up page, the user is asked to enter their email address and select a password:

The corresponding controller action creates the user in the database:

An attacker may inject their own HTML into form (or otherwise modify the request):

The controller action will create the user, letting the attacker gain complete control of the web shop:

How To Defend Against Mass Assignment Attacks

In the example above, the developer should change the code to either explicitly assign the attributes for the allowed fields, or use a whitelisting function provided by the framework (Ruby on Rails in this case):

More useful information may be found at:

• https://www.owasp.org/index.php/Mass_Assignment_Cheat_Sheet
• http://guides.rubyonrails.org/v3.2.9/security.html#mass-assignment
• https://laravel.com/docs/5.0/eloquent#mass-assignment
• https://odetocode.com/Blogs/scott/archive/2012/03/11/complete-guide-to-mass-assignment-in-asp-net-mvc.aspx
• https://coffeeonthekeyboard.com/mass-assignment-security-part-10-855/
• https://nvisium.com/resources/blog/2014/01/17/insecure-mass-assignment-prevention.html

Let Us Review Your Software

We provide code security reviews as a service. Based on our extensive experience in the field of sofware engineering and IT security, we know how to efficiently review entire code bases and identify security critical parts of the software.

This enables us to provide our security code review service at a fixed rate per review, providing our customers a transparent, efficient and reliable process.

• Security review of your software by experts
• OWASP Top 10 vulnerability check
• Security Report with recommendations
• Invaluable insights into the state of security in your application

Fixed Price per Review

• Broken Access Control
• Broken Authentication
• Cross-Site Request Forgery (CSRF)
• Cross-Site Scripting (XSS)
• Insecure Direct Object Reference
• Security Misconfiguration
• Sensitive Data Exposure
• SQL Injection
• Timing Attack
• Unvalidated Redirection
• Vulnerable Dependencies

Technologies

• Microsoft .Net
• Ruby on Rails

ROPE Security is a Software Security Consultancy Firm based in Denmark. Our clients range from large international enterprises to start-ups and small businesses.

If you have any questions, do not hesitate to contact us at [email protected]

Join Our Community on Discord

Duis vehicula hendrerit finibus. In hac habitasse platea dictumst. Quisque aliquet, lacus eget feugiat viverra, diam dui dapibus mauris, at vehicula diam sem vitae nibh.

Mass Assignment

Right now, we’re going to go through Mass Assignment vulnerabilities and what they look like, along with a few ways to avoid them. First, a quick recap: Mass Assignment is a vulnerability where API endpoints don’t restrict which properties of their associated object can be modified by a user. 

This vulnerability can occur when making use of a library/framework that allows for the automatic binding of HTTP parameters onto a model that then goes on to be used without any validation. 

The use of the automatic binding from a request onto an object can be extremely helpful at times, but it can also lead to security issues if the model has properties that aren’t meant to be accessible to the user.

We’re going to use the example of a web page where a user can change details, like their name, email address, and other similar stuff. We have a User model defined as:

public class UserModel {     public long Id { get; set; }     public string Name { get; set; }     public string PasswordHash { get; set; }      public string EmailAddress { get; set; }      public bool IsAdmin { get; set; } } The frontend part defines a form as following. Note the absence of the `IsAdmin` value: <form method="POST">      <input name="Id" type="hidden">      <input name="Name" type="text">      <input name="EmailAddress" type="text">      <input type="submit"> </form>   The controller defines an endpoint as following. By having the `UserModel` as a parameter, our framework will automatically map the respective properties onto this model for us: [HttpPost] public bool UpdateUser(UserModel model) {     // Ensure the user only updates themselves     model.Id = Request.User.UserId;     var success = UserService.UpdateUser(model);     return success;     }

From here, we can assume that the ‘UserService.UpdateUser’ method doesn’t do any further validation in terms of authorization, and simply just saves the provided user object. 

(If no value is provided for a property, it just keeps the existing value) 

This means that a user could submit a request with the ‘IsAdmin’, which would override the current value and make the user an admin like so:

<form method="POST">      <input name="Id" type="hidden" value="666">      <input name="Name" type="text" value="Bad guy">      <input name="EmailAddress" type="text" value="[email protected]">      <input name="IsAdmin" type="hidden" value="true">      <input type="submit"> </form>  

Mitigation strategies.

Below are a few mitigation strategies to consider when it comes to avoiding Mass Assignment vulnerabilities.

Avoid re-using data models for request models

It's important to keep your data models (which may be persisted in a database) separate from the models that get used when communicating with a client. Handling a form submission to a controller is a very different concern from persisting data in a database and how it's represented in the database. This creates a far higher level of coupling between the frontend and the persistence layer than is good. 

Be explicit in your mappings

The problem with automatic binding (or mapping) is that the lack of explicit mappings makes it easy to expose properties that aren’t meant to be accessible on the model. By being explicit in mappings between request models, and the rest of your backend, you can prevent these types of exposures from the start.

This could be done by using different models for requests and data. This doesn't prevent you from using an automatic mapper between the request and data model, as your request model should not expose properties that are not allowed for the specific request.

Further Examples

Below, we’ve got some additional examples in different languages of what this can look like. 

C# - insecure

public class User {      public long Id { get; set; }     public string FirstName { get; set; }     public string LastName { get; set; }     public string PasswordHash { get; set; }     public string Country { get; set; }     public string Role { get; set; } } [HttpPost] public ViewResult Edit( User user) {     // Just saves the user as provided     UserService.UpdateUser(user);     return Ok(); }

C# - secure

public class User {      public long Id { get; set; }     public string FirstName { get; set; }     public string LastName { get; set; }     public string PasswordHash { get; set; }     public string Country { get; set; }     public string Role { get; set; } } public class UpdateUserViewModel {     public string FirstName { get; set; }     public string LastName { get; set; }        public string Country { get; set; } } [HttpPost] public ViewResult Edit(UpdateUserViewModel userModel) {     var user = Request.User;     user.FirstName = userModel.FirstName;     user.LastName = userModel.LastName;     user.Country = userModel.Country;     UserService.UpdateUser(user);      return Ok(); }

C# - alternative - excludes parameters

public class User {      public long Id { get; set; }     public string FirstName { get; set; }     public string LastName { get; set; }     public string PasswordHash { get; set; }     public string Country { get; set; }     public string Role { get; set; } } [HttpPost] public ViewResult Edit([Bind(Include = "FirstName,LastName,Country")] User user) {     if(Request.User.Id != user.Id) {         return Forbidden("Requesting changing of another user");     }     var existingUser = Request.User;     user.PasswordHash = existingUser.PasswordHash;     user.Role = existingUser.Role;     UserService.UpdateUser(user);         return Ok(); }

Java - insecure

public class User {     public int id;     public String firstName;     public String lastName;     public String passwordHash;     public String country;     public String role; } @RequestMapping(value = "/updateUser", method = RequestMethod.POST) public String updateUser(User user) {         userService.update(user);         return "userUpdatedPage"; }

‍ Java - secure

public class UserViewModel {    public String firstName;    public String lastName;    public String country; } public class User {    public int id;    public String firstName;    public String lastName;    public String passwordHash;    public String country;    public String role; } @RequestMapping(value = "/updateUser", method = RequestMethod.POST) public String updateUser(@AuthenticationPrincipal User currentUser, UserViewModel userViewModel) {        currentUser.firstName = userViewModel.firstName;        currentUser.lastName = userViewModel.lastName;        currentUser.country = userViewModel.country;                userService.update(currentUser);        return "userUpdatedPage"; }

Javascript - insecure

app.get('/user/update',  (req, res) => {     var user = req.user;     Object.assign(user, req.body);     UserService.Update(user);      return "User has been updated"; })

Javascript - secure

app.get('/user/update',  (req, res) => {     var user = req.user;     user.firstName = req.body.firstName;     user.lastName = req.body.lastName;     user.country = req.body.country;     UserService.Update(user);     return "User has been updated"; })

Python - Insecure

@app.route("/user/update", methods=['POST']) def update_user():     user = request.user     form = request.form.to_dict(flat=True)     for key, value in form.items():         setattr(user, key, value)     UserService.UpdateUser(user)         return redirect("/user", code=201)

Python - Secure

@app.route("/user/update", methods=['POST']) def update_user():     user = request.user     form = request.form     user.firstName = form.firstName     user.lastName = form.lastName     UserService.UpdateUser(user)     return redirect("/user", code=201)

Injection - XSS

Injection - Path Traversal

Using Components with Known Vulnerabilities

Insufficient Logging and Monitoring

Security misconfiguration - XXE detailed

Security Misconfiguration

Server-Side Request Forgery

Password Storage

Authentication and Authorization

File Upload

Injection 101, sql injection.

Command Injection

Discover the Secure Code Warrior Learning Platform

We secure software through developer-driven security at the start of the software development lifecycle.

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

What does "Mass Assignment" mean in Laravel?

When I went through Laravel Document about Eloquent ORM topic part, I got a new term "Mass Assignment".

Document show How to do Mass Assignment and the $fillable or $guarded properties settings. But after went through that, I didn't have a clearly understand about "Mass Assignment" and how it works.

In my past experience in CodeIgniter, I also didn't hear about this term.

Does anyone have a simple explanation about that?

• mass-assignment

• 4 Some resources Wikipedia or Laravel 4 protects against this vulnerability in a single line of code. Or this post on vulnerability –  user2581096 Commented Mar 9, 2014 at 7:56

5 Answers 5

Mass assignment is when you send an array to the model creation, basically setting a bunch of fields on the model in a single go, rather than one by one, something like:

(This is instead of explicitly setting each value on the model separately.)

You can use fillable to protect which fields you want this to actually allow for updating.

You can also block all fields from being mass-assignable by doing this:

Let's say in your user table you have a field that is user_type and that can have values of user / admin

Obviously, you don't want users to be able to update this value. In theory, if you used the above code, someone could inject into a form a new field for user_type and send 'admin' along with the other form data, and easily switch their account to an admin account... bad news.

You are ensuring that only those values can be updated using mass assignment

To be able to update the user_type value, you need to explicitly set it on the model and save it, like this:

• 21 Thanks for this answer, I quite do not understand who would do such thing as $user = new User(Input::all()); (as programmer) it is so uncontrolled (or in what scenario would be this helpful). –  Kyslik Commented Jul 27, 2014 at 18:41
• 18 ... it's not at all the point of the answer, it's to keep the answer short without hijacking it as a whole lesson on security etc –  duellsy Commented Jul 28, 2014 at 22:17
• 3 I got the point, and I am glad I found this answer. I am just curious in what scenario is line cited above (in my comment) useful. I mean without validation and all that stuff around. –  Kyslik Commented Jul 29, 2014 at 11:27
• 5 so you think in response to a question titled 'What does “Mass Assignment” mean in Laravel?' I should have gone into detail about validation... it was a simple answer to the question without getting off track. Let's leave this as it is. –  duellsy Commented Jul 31, 2014 at 0:43
• 13 It does not matter what is point of the OP question I asked so I do not have to create new thread, and you keep talking about "why not" talk about it. I simply do not understand why would someone use line as you wrote it instead of $user = new User; $user->name = 'Neo'; –  Kyslik Commented Jul 31, 2014 at 11:25

Mass assignment is a process of sending an array of data that will be saved to the specified model at once. In general, you don’t need to save data on your model on one by one basis, but rather in a single process.

Mass assignment is good, but there are certain security problems behind it. What if someone passes a value to the model and without protection they can definitely modify all fields including the ID. That’s not good.

Let's say you have 'students' table, with fields "student_type, first_name, last_name” . You may want to mass assign "first_name, last_name" but you want to protect student_type from being directly changed. That’s where fillable and guarded take place.

Fillable lets you specify which fields are mass-assignable in your model, you can do it by adding the special variable $fillable to the model. So in the model:

the ' student_type ' are not included, which means they are exempted.

Guarded is the reverse of fillable. If fillable specifies which fields to be mass assigned, guarded specifies which fields are not mass assignable. So in the model:

you should use either $fillable or $guarded - not both.

For more details open link:- Mass Assignment

• 4 This is straight out of Matt Stauffer's book "Laravel Up & Running" –  whisk Commented May 24, 2019 at 11:59

Mass assignment means you are filling a row with more than one column using an array of data. (somewhat of a shortcut instead of manually building the array) using Input::all() .

Technically just from the top of my head. Fillable means what columns in the table are allowed to be inserted, guarded means the model can't insert to that particular column.

Notice that when you try to do a mass assignment with like, insert to a column named "secret", and you have specified that it is guarded, you can try to insert to it via the model, but it will never really get inserted into the database.

This is for security, and protection on your table when using the model. Mass assignment seems to be just a notice or warning that you didn't tell the model which are fillable and guarded and makes it vulnerable to some kind of attacks.

This is when an array of data received is saved at once in a model.

Because of the security issues with this method in laravel, it's recommended you define the fields you wish the requested data to populate on the Model.

You can use the $fillable variable to define the fields you want to populate on the database table.

When laravel detects you are mass assigning data, it forces you to define the fields you want to mass assign in the model class.

Someone can easily pass unwanted data into an html form to your database.

• 1 Please do not post images of code/error messages. –  Don't Panic Commented Nov 14, 2022 at 11:27

Not the answer you're looking for? Browse other questions tagged php laravel eloquent mass-assignment or ask your own question .

• The Overflow Blog
• One of the best ways to get value for AI coding tools: generating tests
• The world’s largest open-source business has plans for enhancing LLMs
• Featured on Meta
• User activation: Learnings and opportunities
• Site maintenance - Mon, Sept 16 2024, 21:00 UTC to Tue, Sept 17 2024, 2:00...
• What does a new user need in a homepage experience on Stack Overflow?
• Announcing the new Staging Ground Reviewer Stats Widget

Hot Network Questions

• Is it defamatory to publish nonsense under somebody else's name?
• Browse a web page through SSH? (Need to access router web interface remotely, but only have SSH access to a different device on LAN)
• Why does counterattacking lead to a more drawish and less dynamic position than defending？
• mmrm R package : No optimizer led to a successful model fit
• How to Place a Smooth "Breathing" Above the E with Textgreek?
• How do elected politicians get away with not giving straight answers?
• Is it safe to use the dnd 3.5 skill system in pathfinder 1e?
• Is it really a "space walk" (EVA proper) if you don't get your feet wet (in space)?
• Movie where a young director's student film gets made (badly) by a major studio
• What prevents indoor climbing gyms from making a v18 boulder even if one hasn't been found outside?
• Whom did Jesus' followers accompany -- a soldier or a layman?
• How to avoid bringing paper silverfish home from a vacation place?
• How did NASA figure out when and where the Apollo capsule would touch down on the ocean?
• Subject verb agreement - I as well as he is/am the culprit
• Definition of annuity
• Why did early ASCII have ← and ↑ but not ↓ or →?
• How can I analyze the anatomy of a humanoid species to create sounds for their language?
• How to decrease by 1 integers in an expl3's clist?
• Why was Panama Railroad in poor condition when US decided to build Panama Canal in 1904?
• Keyboard shortcuts for running last command with changes?
• Is it true that before European modernity, there were no "nations"?
• Why was Esther included in the canon?
• Strange behavior of Polygon with a hole
• If Act A repeals another Act B, and Act A is repealed, what happens to the Act B?

• Use Cases Overview
• Use Case Breakdown
• Automated Penetration Testing
• API Security Validation at Scale
• Zero Trust Security Validation
• Deep Dynamic Application Security Testing (DAST)
• Zero day as a Service (ZDaaS)
• Book a demo

Introduction

Mass Assignment refers to the risk of insecurely handling user input in APIs, which can allow attackers to modify or manipulate data in unintended ways. This can occur when APIs do not properly validate or sanitize user input, or when APIs allow direct assignment of user input to object properties without proper authorization or validation.

Some common risks associated with Mass Assignments include:

• Unauthorized modification or manipulation of data
• Elevation of privileges by unauthorized parties
• Compromise of user accounts

Attack Scenarios

Attack scenarios for cloud applications may include:

• An attacker intercepts an API call and modifies the request to modify or manipulate data in unintended ways
• An attacker exploits a vulnerability in the API to directly assign user input to object properties, bypassing authorization or validation checks
• An attacker uses an API to send malicious input in an attempt to exploit vulnerabilities or inject malicious code

Vulnerable Sample Code

A vulnerable sample of code in Go lang might look like this:

In this example, the API call allows a user to update their own data in a database. However, the API directly assigns the user input from the request body to the properties of a User struct without any validation or authorization checks. An attacker could exploit this vulnerability by intercepting the API call and modifying the request body to update the user’s data in unintended ways, such as changing the user’s role or password.

Sample Attack

A sample attack payload using the curl command might look like this:

In this example, the attacker is using curl to send a PUT request to the API with a modified user ID in the request header and a modified request body that includes a new email, password, and role for the user. If the API is vulnerable to Mass Assignment, the attacker may be able to update the user’s data in unintended ways.

MITRE ATT&CK framework reference

Mass Assignment can be mapped to the Tactic: Privilege Escalation and the Techniques: Exploitation of Uncontrolled Linkage to a Third-party

• Whitelisting: Only allow specific properties to be modified by the API. This can be done by using a whitelist of properties that are allowed to be modified, and rejecting any request that includes properties that are not on the whitelist.
• Strong data validation: Ensure that all data sent to the API is valid and conforms to the expected format. This can be done by using input validation libraries or by manually validating the data.
• Access control: Limit the API’s access to specific users or roles. This can be done by using role-based access control (RBAC) or by using API keys.
• Use of ORM: Use Object-Relational Mapping (ORM) frameworks like Entity Framework, Hibernate etc. These frameworks automatically handle the mass assignment vulnerability by not allowing the modification of properties that are not explicitly included in the mapping.
• Logging and monitoring: Keep track of all API requests and responses and log any suspicious activity. This will help you detect any mass assignment attempts and take appropriate action.
• Secure the API endpoints: Use HTTPS to encrypt the communication between the client and the API, and also use authentication and authorization mechanisms to limit access to the API.

Download API Security whitepaper

Our in-depth whitepaper provides valuable insights into how Prancer Security’s cutting-edge solution mitigates critical risks such as unauthorized access and data breaches, while adhering to the highest security standards.

Don’t leave your API security to chance – download our comprehensive whitepaper now and discover how Prancer Security can safeguard your organization from potential threats!

• #API Security

LRQA Nettitude Command & Control Framework - Free and Open Source

Vulnerability research, regular vulnerability disclosures, red team training, learn to be the best, from the best, explaining mass assignment vulnerabilities.

Programming frameworks have gained popularity due to their ability to make software development easier than using the underlying language alone. However, when developers don’t fully understand how framework functionality can be abused by attackers, vulnerabilities are often introduced.

One commonly used framework feature is known as mass assignment, a technique designed to help match front end variables to their back end fields, for easy model updating.

Implementing mass assignment

We’ll be using PHP/Laravel as an example to demonstrate how mass assignment works via the Laravel framework. Let’s imagine you have a form which allows a user to update some of their profile details, and that form contains the following fields:

Within the Laravel controller, one way to update those fields would be as follows:

An alternative way to do this would be to take advantage of mass assignment, which would look something like this:

This code updates the User model with the values from the Request (in this case the HTML fields for name, email, address and phone) assuming that the input names match the models fields. This obviously saves superfluous lines of code, since all fields can be updated at once, instead of specifying individually.

The mass assignment vulnerability

So, how might an attacker exploit this?

As may be evident from the code above, the framework is taking all the input fields from the Request variable and updating the model without performing any kind of validation. Therefore, its trusting that all the fields provided are intended to be updateable.

Although the example currently only provides options for updating fields such as name and email, there are usually more columns in the User table which aren’t displayed on the front end. In this case, lets imagine that there is also a field named role , which determines the privilege of the user. The role field wasn’t displayed in the HTML form because the developers didn’t want users changing their own role.

However, with our understanding that the controller is simply trusting all input provided by the request to update the User model, an attacker can inject their own HTML into the page to add a field for role , simply by using built in browser tools. This can also be done by intercepting the request using a proxy and appending the field name and value, or by any other technique that allows client side modification.

This time, when the controller is reached, the user model will be updated with the expected fields (name, email, address, phone) as well as the additional role field provided.  In this case, the vulnerability leads to privilege escalation.

This particular example demonstrates how mass assignment can be exploited to achieve privilege escalation, however it is often possible to bypass other controls using the same technique. For example, an application might prevent a username from being edited when updating profile information, to ensure integrity and accountability across audit trails. Using this attack, a user could perform malicious actions under the guise of one username before switching to another.

Countermeasures

There are several ways to protect against mass assignment attacks. Most frameworks provide defensive techniques such as those discussed in this section.

The general idea is to validate input before updating the model. The safest way to do this is to somewhat fall back to the original and more convoluted process of specifying each field individually. This also has the added benefit of providing the ability to add additional validation to each field beyond ensuring only expected fields are updated.

In Laravel, one way to do this would be as shown below; include some validation such as the maximum number of permissible characters for the name field, and then update the User model with the validated data. As the validate() function lists the exact fields expected, if the role field was appended as demonstrated in our previous sample attack, it would be ignored and have no effect.

An alternative method is to utilize allow lists and deny lists to explicitly state what fields can and cannot be mass assigned. In Laravel, this can be done by setting the $fillable property on the User model to state which fields may be updated in this way. The code below lists the four original fields from the HTML form, so if an attacker tried to append the role field, since its not in the $fillable allow list, it won’t be updated.

Similarly, deny lists can be used to specify which fields cannot be updated via mass assignment. In Laravel, this can be done using the $guarded property in the model instead. Using the following code would have the same effect as the above, since the role parameter has been deny listed.

Mass assignment vulnerabilities are important issues to check for during software development and during penetration tests because they are often not picked up by automated tools, due to them often having a logic component. For example, a tool will not likely have the context to understand if a user has managed to escalate their privilege after a specially crafted request.

They are also often overlooked by developers, partly due to lack of awareness for how certain features can be exploited, but also due to pressure to complete projects since its faster to use mass assignment without performing input validation.

It’s important to understand that mass assignment vulnerabilities exist and can be exploited with high impact. A strong software development lifecycle and associated testing regime will reduce the likelihood of these vulnerabilities appearing in code.

Share This Story, Choose Your Platform!

Related posts.

How to prevent mass assignment in ASP.NET Core

One of the many security risks which you should consider is a mass assignment vulnerability ( cheatsheet ) also know as overposting. While it’s not in OWASP Top 10 it’s still considered important. Read on to understand the issue and find out possible ways of fixing it.

Mass assignment explained

ASP.NET Core allows automatic model binding of request parameters into variables or objects to make developers life easier. It can be as simple as binding id parameter via route:

It can also be more complicated, for example we can bind a bunch of GET parameters into custom model:

This behavior can be harmful. Attacker can guess parameter names and overwrite variables which should remain intact.

Let’s see how this works by example. Let’s assume that we have a simple web application where users can change login and password.

This is our database model:

This is the view with password change form:

And this is how our action looks like:

If the user found out that we’re having Role property, he could try to overwrite it and set it to “admin”.

Now, what would happen if attacker crafted a malformed request like this:

In this scenario our evil user could promote his account to admin, because there is nothing in our code to prevent that.

We may think that we’re safe because we haven’t included Role property in our form or we made it hidden, but it doesn’t prevent proper binding.

How to deal with it?

This vulnerability happens during model binding when someone is trying to create request in a way which allows overriding model properties.

There are a couple of security countermeasures to help us prevent mass assignment.

As we’ll see there are two groups of solutions for this problem. First is to manually specify which properties should or shouldn’t be binded (whitelisting/blacklisting) using data annotations. Second is to add another layer to our application (view models).

The bad approach

While you could technically fix this problem by manually nulling/zeroing all other variables, you shouln’t follow this way. It’s error prone, verbose and we’ve better solutions available out of the box.

So I strongly advise against doing something like this:

BindAttribute

One way to prevent binding of unwated properties is to use [Bind] attribute on model.

We can use it to pick only bindable properties:

Other model properties would simply be ignored, so even if someone posted Role property it wouldn’t be binded to model. We’re basically whitelisting properties here.

Unfortunately this solution uses magic strings, so if you decide to change your property name (e.g. Login to Username ) you will have to remember and change it manually.

Pretty error prone solution if you ask me, but since we have the nameof operator there is a way to make it a litte bit better (and more verbose):

EditableAttribute / BindNeverAttribute / ReadOnlyAtribute

Next possibility is to use one of property attributes which will prevent binding:

• [BindNever]
• [Editable(false)]

Those attributes has to be used directly on model fields like so:

Most appropriate in my opinion would be BindNever , the other one seems to not be appropriate in this case.

TryUpdateModelAsync

Controllers have a neat little method called TryUpdateModelAsync which helps us update only specified fields:

The drawback of this solution is that TryUpdateModelAsync is tied to controller, so if you (want to) have a separate database services layer it will cause some trouble.

Also you may dislike this solution because it tends to put too much database related operations into controller.

ViewModel / Data Transfer Object

Many would say that it’s best to provide additional layer which would be responsible for data exchange between controller and view.

Separation of concerns is a good idea, after all database model is not the same as view model.

Besides introducing data transfer objects / view models layer to our app can help us prevent mass assignment vulnerabilities.

This way we have view-models with minimum required properties which are mapped to EntityFramework models afterwards.

Providing additional layer has its own drawback which is extra work. It takes some time to create additional classes and view model to model mapping, but in return we’re having a better layered application.

We can use solutions like Automapper to help us map values from view-model to database model and back.

If you’re building an (JSON) API: attributes won’t work with [FromBody] !

Model binding using different formatters (JSON, XML, etc) won’t take standard attributes into account.

Simply model binding knows nothing about your serializer/deserializer, so regular attributes won’t apply.

You can try to check if your serializer has build-in attributes which could replace [BindNever] e.g. Json.NET has [JsonIgnore] which could be used to prevent binding.

What you can do in this case:

• use data attributes provided by your serializer/deserializer
• write custom binder which would take attributes into account
• use data transfer object approach.

In my opinion it’s best not to bind directly to database model. Personally I avoid attribute based solutions.

I prefer to have separate view-model layer and binding directly to entity models doesn’t appeal to me. In return we have separation of concerns and we’re hiding internal (database) data structures away from users.

Though most people would probably use attribute based approach for basic stuff and view-models for advanced apps.

Don’t forget that you may need different security measures when you’re accepting JSON (or other) formatted requests.

Author Zbigniew

LastMod 2018-03-02

• Election 2024
• Entertainment
• Newsletters
• Photography
• AP Investigations
• AP Buyline Personal Finance
• AP Buyline Shopping
• Press Releases
• Israel-Hamas War
• Russia-Ukraine War
• Global elections
• Asia Pacific
• Latin America
• Middle East
• Election results
• Google trends
• AP & Elections
• College football
• Auto Racing
• Movie reviews
• Book reviews
• Financial Markets
• Business Highlights
• Financial wellness
• Artificial Intelligence
• Social Media

Oracle settles suit over tracking your data. How to file a claim

FILE - A sign for Oracle Corporation is seen outside their offices in Santa Monica, Calif. on June 21, 2023. (AP Photo/Richard Vogel, File)

• Copy Link copied

NEW YORK (AP) — Tech behemoth Oracle has agreed to settle a class action lawsuit for $115 million over allegations that it tracked consumer activity both on and offline.

The suit alleges Oracle captured, compiled, and sold individuals’ data to third parties without their consent. Oracle maintains its practices were lawful, that it disclosed its activities, and it admitted no wrongdoing.

Under the class action settlement, Oracle will pay $115 million to establish a settlement fund, and anyone residing in the United States from August 19, 2018 to the present who was affected may be eligible to file a claim. The fund will also cover up to $28.75 million for attorneys fees and other costs. All valid claimants will receive the same amount of money, which is dependent on how many people file.

If you browsed the web, used geolocation services, or made in-store purchases electronically during the six-year period addressed in the settlement, you may be eligible. Allegedly, Oracle Advertising improperly collected personal data from these activities and subsequently sold or made that data available to third parties. The company allegedly did so using Oracle Advertising products including ID Graph and Data Marketplace.

“All natural persons residing in the United States whose personal information, or data derived from their personal information, was acquired, captured, or otherwise collected by Oracle Advertising technologies or made available for use or sale by or through ID Graph, Data Marketplace, or any other Oracle Advertising product or service from August 19, 2018 to the date of final judgment in the Action” are eligible, according to the settlement website .

The court will decide whether to approve the proposed settlement at a hearing on November 14, 2024.

Claims may be filed online on the official settlement website or by mail. Claims must be filed by October 17, 2024.

Shares of Oracle Corp, based in Austin, Texas, rose slightly on Friday.

“The Associated Press receives support from Charles Schwab Foundation for educational and explanatory reporting to improve financial literacy. The independent foundation is separate from Charles Schwab and Co. Inc. The AP is solely responsible for its journalism.”