mass assignment vulnerability remediation

• 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

Mass Assignment Vulnerabilities

Web application security is of critical importance in today’s digital landscape. Developers need to be aware of various vulnerabilities that malicious actors can exploit. One such critical vulnerability is “Mass Assignment Vulnerability,” a commonly overlooked security flaw in web applications. This article aims to shed light on the nature of this threat, its implications, and how developers can prevent it. Additionally, we’ll provide an example of vulnerable PHP code to help illustrate the concept.

• Anthony Cole
• September 15, 2023

Table of Contents

What is mass assignment vulnerability.

Mass Assignment Vulnerability occurs when a web application allows users to submit a more extensive set of data than is intended or safe. Typically, this vulnerability arises due to careless handling of user inputs and inadequate validation and sanitization. In some cases, the developer might intend to allow specific data updates using a particular request but unintentionally enables the modification of sensitive or protected fields.

The potential consequences of this vulnerability can be severe, as attackers can exploit it to alter data, escalate privileges, or even gain unauthorized access to critical system components. Therefore, it is crucial for developers to identify and mitigate this vulnerability in their applications.

Example of Vulnerable PHP Code

Consider a hypothetical scenario with a PHP-based web application that allows users to update their profile information, such as name, email, and account type. The developer has created a simple class to handle user updates:

In this code snippet, the developer fetches a JSON object from the POST body and directly uses it to update the user’s profile without proper validation. An attacker could manipulate the POST request, including additional data fields like ‘isAdmin’ or ‘isActivated,’ which should never be allowed to be modified by regular users.  The above code also implements an auto-mapper functionality that populates the User class properties with the corresponding values found in the $userObject object, which is user-controlled input. In figure 2 an example of a HTTP request with the expected JSON input object can be seen. In figure 3, a request showing how the “isAdmin” property can be updated is shown.

To prevent a user from populating class properties that should be inaccessible, an allow list should be implemented as seen in the code below. The highlighted code defines an allow list containing the “name” and “email” properties.  When the auto-mapper assigns values to the class properties, the current property is checked against the allow list.

Mitigation Techniques

To prevent Mass Assignment Vulnerabilities, developers can implement the following best practices:

• Allowlist Input: Only update specific, intended fields. Create a list of allowed fields and update only those explicitly mentioned in the whitelist.
• Blocklist Rejected Fields: If the application requires users to update almost all fields except a few, developers can create a blocklist of disallowed fields.
• Input Validation: Always validate and sanitize user inputs to ensure they adhere to the expected format and are free from malicious data.
• Role-based Access Control (RBAC): Implement RBAC to define different user roles and permissions, ensuring that sensitive fields are only accessible to authorized personnel.
• Use Frameworks with Built-in Protection: Utilize web application frameworks with built-in security mechanisms to prevent Mass Assignment Vulnerabilities.

Mass Assignment Vulnerabilities pose a significant threat to web applications, potentially allowing attackers to manipulate critical data and gain unauthorized access. Developers must be vigilant and implement robust input validation and access control mechanisms to prevent this vulnerability. Developers can create more secure web applications and protect sensitive user data from potential breaches by adhering to best practices, testing and staying updated on the latest security measures.

Anthony Cole, Sr. Penetration Tester at Redbot Security

Anthony Cole is a Sr. Security Consultant with over 22 years of experience in information technology, IT security and software development. Anthony is fully GIAC certified in all facets of information security, enabling him to facilitate successful outcomes for customers. Anthony’s vast knowledge of both offensive and defensive security ensures that Redbot Security’s customers will receive the best service in the industry.

Anthony is Redbot Security’s AppSec SME and formerly a Sr. Level Application Penetration Testing Engineer for NetSpi and Presidio as well as Blutique LLC’s Chief Technical Officer and Sr. Application Developer.

Pen-Test Project Quote

Our expert team will help scope your project and provide a fast and accurate project estimate.

Popular Keywords

No Record Found

Related Articles

Beyond the Top 5: ICS/SCADA IT/OT Security

Is your security team sharing sensitive data unknowingly?

PHP Insecure Deserialization

Attackers can manipulate the serialized data to execute malicious code, compromise the application, or gain unauthorized access.

From Military Cyberwarfare to Commercial Pen Testing

The following article is a discussion about helping you to best utilize your military skills to successfully transition into the commercial space.

ICS/SCADA Penetration Testing: Where to Start

Becoming proficient in Operational Technology (OT), Industrial Control Systems (ICS), and Supervisory Control and Data Acquisition (SCADA) network testing can appear daunting as there are fewer learning resources.

Machine Learning & Artificial Intelligence

Machine Learning (ML) is a subset of AI, and, more than likely, closely aligns with what we consider to be AI in the media.

Insecure Direct Object Reference (IDOR)

Insecure Direct Object Reference (IDOR) vulnerabilities pose a significant risk to the security of web applications, allowing attackers unauthorized access to sensitive data and functionalities. By understanding the implications of IDOR and adopting secure coding practices, web developers can protect their applications and users from potential exploitation.

Application Security – JavaScript Web Tokens

The following article is a discussion that explores JavaScript Web Tokens

Examining the Modbus Protocol from an Offensive Security Perspective

While plenty of articles cover the Modbus protocol with varying degrees of detail and usage, this article aims to examine the Modbus protocol with an offensive security lens.

Evolving Your Cybersecurity: From Penetration Testing to Red Teaming

While penetration testing is valuable in identifying technical vulnerabilities, red teaming provides a more holistic assessment by simulating realistic threat scenarios. By embracing red teaming, organizations can bolster their defenses, uncover weaknesses, and stay one step ahead of sophisticated adversaries.

Wireless Penetration Testing Services

The following article is a discussion that explores Wave Behaviors to Locate Wireless Access Points and Devices

Additional Articles

Offensive security, what is social hacking, what you need to know about pci penetration testing, what is penetration testing (pen-testing), our nation under attack, manual penetration testing – manual testing vs automated testing, what is penetration testing & its different types, common cybersecurity issues that are easy to fix, security management platform, cyber threat news feed.

Check out the latest cybersecurity news around the globe

Redbot Security is a boutique penetration testing firm with a Sr. Level Team of cybersecurity experts. The entire team of Redbot Security is passionate about delivering cost-effective solutions that consider customers’ goals and priorities first.

• Customer Reviews
• Network Pen-Testing
• App Pen-Testing
• Wireless Testing
• ICS/SCADA Testing
• Red Teaming
• Cloud Security
• Social Engineering
• News and Updates
• Tech Insight Articles

© Copyright 2016-2023 powered by REDBOT SECURITY

OWASP Testing Guide

Testing for mass assignment (wstg-inpv-20).

Modern web applications are very often based on frameworks. Many of these web application frameworks allow automatic binding of user input (in the form of HTTP request parameters) to internal objects. This is often called autobinding. This feature can be sometimes exploited to access fields that were never intended to be modified from outside leading to privilege escalation, data tampering, bypass of security mechanisms, and more. In this case there is a Mass Assignment vulnerability.

Examples of sensitive properties:

Permission-related properties : should only be set by privileged users (e.g. is_admin , role , approved ).

Process-dependent properties : should only be set internally, after a process is completed (e.g. balance , status , email_verified )

Internal properties : should only be set internally by the application (e.g. created_at , updated_at )

• Test Objectives

Identify requests that modify objects

Assess if it is possible to modify fields never intended to be modified from outside

• How to Test

The following is a classic example that can help to illustrate the issue.

Suppose a Java web application with a User object similar to the following:

To create a new User the web application implements the following view:

The controller that handles the creation request (Spring provides the automatic bind with the User model):

When the form is submitted, the following request is generated by the browser:

However, due to the autobinding, an attacker can add the isAdmin parameter to the request, which the controller will automatically bind to the model.

The user is then created with the isAdmin property set to true , giving them administrative rights on the application.

• Black-Box Testing

Detect Handlers

In order to determine which part of the application is vulnerable to mass assignment, enumerate all parts of the application that accept content from the user and can potentially be mapped with a model. This includes all HTTP requests (most likely GET, POST, and PUT) that appear to allow create or update operations on the back end. One of the most simple indicators for potential mass assignments is the presence of bracket syntax for input parameter names, as for example:

When such patterns are encountered try to add an input related to a non-exiting attribute (e.g. user[nonexistingattribute] ) and analyze the response/behavior. If the application does not implement any control (e.g. list of allowed fields) it is likely that it will respond with an error (e.g. 500) due to the fact that the application does not find the attribute associated to the object. More interestingly, those errors sometimes facilitate discovery of attribute names and value data types needed to exploit the issue, without access to the source code.

Identify Sensitive Fields

Since in black-box testing the tester does not have visibility on the source code, it is necessary to find other ways in order to gather information about the attributes associated to the objects. Analyze the responses received by the back end, in particular pay attention to:

HTML page source code

Custom JavaScript code

API responses

For example, very often, it is possible to exploit handlers that return details about an object in order to gather clues on the associated fields. Suppose for example a handler that returns the profile of the user (e.g. GET /profile ), this may include further attributes related to the user (in this example the isAdmin attribute looks particularly interesting).

Then try to exploit handlers that allow the modification or creation of users, adding the isAdmin attribute configured to true .

Another approach is to use wordlists in order to try to enumerate all the potential attributes. The enumeration can then be automated (e.g. via wfuzz, Burp Intruder, ZAP fuzzer, etc.). The sqlmap tool includes a common-columns.txt wordlist that can be useful to identify potential sensitive attributes. A small example of common interesting attribute names are the following:

is_administrator

isAdministrator

administrator

When multiple roles are available try to compare requests made by different user levels (pay particular attention to privileged roles). For example, if extra parameters are included in requests made by an administrative user, try those as a low privileged/anonymous user.

Check Impact

The impact of a mass assignment can vary depending on the context therefore, for each test input attempted in the previous phase, analyze the result and determine if it represents a vulnerability that has a realistic impact on the web application's security. For example, the modification of the id of an object can lead to application Denial of Service or privilege escalation. Another example is related to the possibility to modify the role/status of the user (e.g. role or isAdmin ) leading to vertical privilege escalation.

• Gray-Box Testing

When the analysis is performed with a gray-box testing approach, it is possible to follow the same methodology to verify the issue. However, the greater knowledge on the application allows to more easily identify frameworks and handlers subject to mass assignment vulnerability. In particular, when the source code is available, it is possible to search the input vectors more easily and accurately. During a source code review, use simple tools (such as the grep command) to search for one or more common patterns within the application code. Access to the DB schema or to the source code allows also to easily identify sensitive fields.

Spring MVC allows to automatically bind user input into object. Identify the controllers that handle state-changing requests (e.g. find the occurrences of @RequestMapping ) then verify if controls are in place (both on the controller or on the involved models). Limitations on the exploitation of the mass assignment can be, for example, in the form of:

list of bindable fields via setAllowedFields method of the DataBinder class (e.g. binder.setAllowedFields(["username","password","email"]) )

list of non-bindable fields via setDisallowedFields method of the DataBinder class (e.g. binder.setDisallowedFields(["isAdmin"]) )

It is also advisable to pay attention to the use of the @ModelAttribute annotation that allows to specify a different name/key.

Laravel Eloquent ORM provides a create method which allows automatic assignment of attributes. However, the latest versions of Eloquent ORM provide default protection against mass assignment vulnerabilities requiring to explicitly specify allowed attributes that can be assigned automatically, through the $fillable array, or attributes that have to be protected (non-bindable), trough the $guarded array. Therefore by analyzing the models (classes that extend the Model class) it is possible to identify which attributes are allowed or denied and therefore point out potential vulnerabilities.

Model binding in ASP.NET automatically bind user inputs to object properties. This also works with complex types and it will automatically convert the input data to the properties if the properties' names match with the input. Identify the controllers then verify if controls are in place (both inside the controller or in the involved models). Limitations on the exploitation of the mass assignment can be, for example, in the form of:

fields declared as ReadOnly

list of bindable fields via Bind attribute (e.g. [Bind(Include = "FirstName, LastName")] Student std ), via includeProperties (e.g. includeProperties: new[] { "FirstName, LastName" } ) or through TryUpdateModel

list of non-bindable fields via Bind attribute (e.g. [Bind(Exclude = "Status")] Student std ) or via excludeProperties (e.g. excludeProperties: new[] { "Status" } )

• Remediation

Use built-in features, provided by frameworks, to define bindable and non-bindable fields. An approach based on allowed fields (bindable), in which only the properties that should be updated by the user are explicitly defined, is preferable. An architectural approach to prevent the issue is to use the Data Transfer Object (DTO) pattern in order to avoid direct binding. The DTO should include only the fields that are meant to be editable by the user.

OWASP: API Security

OWASP: Cheat Sheet Series

CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

Last updated 1 year ago

WSTG-INPV-20

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

A Pentester’s Guide to SQL Injection (SQLi)

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

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

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

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.

Mass Assignment

Description ​.

We sent a payload with extra properties relating to RBAC and they were accepted. This means that the object was not properly sanitized and special properties can be forced into the object.

Remediation ​

You must validate all objects and all their properties, even when not documented in the API.

REST Specific ​

In ASP.NET, to prevent mass assignment vulnerabilities, use view models with only the properties that should be updated and apply the [Bind] attribute to limit properties that can be bound. Additionally, avoid using the UpdateModel or TryUpdateModel methods with your domain models directly. Always validate and sanitize input before applying changes to the data model.

In Ruby on Rails, prevent mass assignment vulnerabilities by using strong parameters. Explicitly permit only the required parameters for an object using the permit method in the controller. For example, if you have a User model, define a private method in the UsersController that whitelists the user parameters like so: params.require(:user).permit(:name, :email) . This ensures that only the allowed attributes can be set through mass assignment.

In Next.js, to prevent mass assignment vulnerabilities, ensure that you explicitly define the properties that can be updated. Use libraries like lodash or ES6 functions to pick only the allowed fields from the request body before passing them to your data update functions. Additionally, consider using TypeScript for stronger typing and compile-time checks.

In Laravel, to prevent mass assignment vulnerabilities, always define fillable or guarded properties in your Eloquent models. Use the 'fillable' property to specify which attributes should be mass-assignable. Alternatively, use the 'guarded' property to define which attributes are not mass-assignable. Additionally, leverage Form Request validation to ensure only expected data is passed through and consider using DTOs (Data Transfer Objects) for complex data handling. Regularly review your code to ensure that mass assignment protections are in place and effective.

In Express.js, to prevent mass assignment vulnerabilities, use middleware like express-validation to validate incoming data against a predefined schema, or manually define a list of allowed fields and only accept those. Additionally, consider using ORMs like Sequelize or Mongoose that support field whitelisting.

In Django, ensure that you define explicit fields in your forms or serializers that correspond to the model attributes you want to allow for mass assignment. Use the 'fields' attribute in ModelForm or the Django REST Framework serializers to control which fields are accepted. Additionally, leverage the 'exclude' attribute to specify any fields that should not be included in the form or API input. Always validate incoming data and consider using the '@property' decorator to define read-only properties that cannot be set through mass assignment.

In Symfony, to prevent mass assignment vulnerabilities, use the 'allow_extra_fields' option in your form configuration and set it to 'false'. This ensures that only the fields explicitly defined in the form will be accepted. Additionally, explicitly define the properties that should be mutable by using the 'property_path' option for each field, and avoid using the 'handleRequest' method with untrusted data sources. Always validate and sanitize input data before binding it to your models.

In Spring Boot, to prevent mass assignment vulnerabilities, use DTOs (Data Transfer Objects) to explicitly define the properties that should be bound from the request payloads. Additionally, leverage the @JsonIgnoreProperties annotation to ignore unexpected fields, and use @JsonProperty(access = Access.READ_ONLY) on fields that should not be writable. Always validate input and consider using groups with @Validated to apply different validation rules for different operations.

In Flask, to prevent mass assignment vulnerabilities, ensure that you explicitly define which fields can be modified by the user. Use forms or serializers to whitelist allowed fields and ignore any unexpected fields sent in the request. Additionally, leverage the Flask-WTF or Marshmallow libraries to enforce strict input validation and deserialization. Always avoid directly passing request data to ORM save or update methods without proper filtering.

In Nuxt.js, to prevent mass assignment vulnerabilities, explicitly define the properties that should be allowed in your models or data objects. Use libraries like vue-safe-html for sanitizing input and consider implementing a strict allowlist of permissible fields when handling user input. Additionally, leverage Nuxt.js middleware to validate and sanitize incoming data before it reaches your application logic.

In FastAPI, to prevent mass assignment vulnerabilities, explicitly define which fields are allowed to be updated in your Pydantic models using the Field function with the exclude parameter. Additionally, use the Body function with the embed parameter to ensure that only the specified fields can be received from the request payload. Implement role-based access control (RBAC) checks to ensure users can only modify fields they are authorized to change.

Configuration ​

Identifier: injection/mass_assignment

Ignore this check ​

• Escape Severity: HIGH

Compliance ​

• OWASP: API1:2023
• pci: 6.5.10
• gdpr: Article-32
• psd2: Article-95
• iso27001: A.18.1
• nist: SP800-53
• fedramp: AC-6

Classification ​

• CVSS_VECTOR: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
• CVSS_SCORE: 9.3
• Description
• REST Specific
• Classification

• 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]

• 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.

• Agile Security
• App Security Testing
• Application Control Audit
• Application Protection
• Application Security Assessment
• Application Security Best Practices
• Application Security Risk
• Application Security Tools
• Application Testing Tool
• Automated Web Testing
• Automated Penetration Testing Tools
• Black Box Analysis
• Blackbox Test
• Black Box Testing
• Blackbox Testing Techniques
• Cloud-based Security 
• Code Review Tools
• Code Security Analysis
• Data Breach
• Data Loss Prevention Guide
• Data Security
• Ethical Hacking
• Gray Box Testing
• Mobile app security testing
• Network security tools
• Open Source Risk
• OWASP Testing Tools
• OWASP Top 10
• Penetration Testing
• SaaS Application Security
• SaaS Application Monitoring
• Secure Applications
• Security Review Software
• Software Audit
• Software Code Security
• Software Security
• Software Testing
• Software Testing Process 
• Software Testing Tools
• Source Code Analysis
• Source Code Security Analyzer
• Static Analysis
• Static Code Analysis
• Third-Party Risk Assessment
• Unit Testing
• Vulnerability Assessment
• Vulnerability Assessment Software
• Vulnerability Management
• Vulnerability Scanning Tools
• Web App Penetration Testing
• Web Application Audit
• Web Application Monitoring
• Web Application Scanning
• Web Application Security Testing
• Web Application Testing
• Web Application
• Web application scanner
• Web pen testing
• What is Third-Party Software?
• NIST Compliance
• OWASP security
• Secure Compliance
• Web Application Security Standards
• PCI Security
• Agile Software Development Lifecycle
• Android Security
• DAST Assessment
• DevOps Security
• DevOps Testing
• JavaScript Security
• Linux Hacking
• Microservices
• Mobile App Testing
• Ruby Security
• Secure Development
• Secure DevOps
• Secure Web Application Development
• Software Development Lifecycle (SDLC)
• Web Application Penetration Testing
• Integrated Development Environment
• Software containers
• Software Testing Methodologies and Techn...
• What is Systems Development Life Cycle
• Application Vulnerability
• ARP Spoofing
• Buffer Overflow
• Computer Worm
• Credentials Management Flaws
• CRLF Injection
• Cross Site Scripting Prevention
• Cross Site Scripting Vulnerability
• Cross-Site Request Forgery
• Cross-Site Scripting
• Directory Traversal
• Encapsulation
• Error Handling Flaws
• Failure to Restrict URL Access
• Insecure Cryptographic Storage
• Insufficient Transport Layer Protection
• LDAP Injection
• Malicious Code
• Man in the Middle Attack
• Mobile Code Security
• Open Source Vulnerabilities
• OS Command Injection
• PHP SQL injection test
• Preventing XSS
• Race Condition
• Reflected XSS
• Session management
• Spoofing Attack
• SQL Injection Scanner
• SQL Attacks
• SQL Injection .NET
• SQL cheat sheet
• SQL Injection
• SQL Injection Java
• What is a worm
• What is SQL Injection
• CWE 73: External Control of File Name or...
• CWE 78: OS Command Injection
• CWE 80: Cross-Site Scripting
• CWE 89: SQL Injection
• CWE 117: Improper Output Sanitization fo...
• CWE 209: Information Exposure Through an...
• CWE 601: Open Redirects
• CWE 639: Insecure Direct Object Referenc...
• CWE 915: Improperly Controlled Modificat...
• Android Hacking
• Facebook Security
• iOS Security
• Password Hacking
• Role based access controls
• Wireless Sniffer
• Testing tools for Mobile
• Vendor Application Security Testing

APPLICATION SECURITY

Knowledge Base

Search Our Knowledge Base

CWE 915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

CWE 915: Improperly Controlled Modification of Dynamically-Determined Object Attributes , also known as overpost or mass-assignment , is a flaw in which an application accepts input data and does not properly control which elements are allowed to be modified. In ASP.NET MVC model binding simplifies the mapping of incoming (untrusted) data to the controller action method parameters. Although it is very helpful you can use it to perform validation, you need to use it carefully. For example:

The above code shows an entity framework datbase-context called UserDbContext that exposes a generic DbSet collection for UserAccount . Entity Framwork is an Object Relational Mapper (ORM) that helps the developer storing data in a database. The following is a ASP.NET MVC controller implementation called AccountController that contains the update method UpdateUserAccount() that updates user details.

The above HTTP POST action accepts the method argument account , which is of type UserAccount . The ASP.NET MVC model binder will populates account instance variable with all the requested data elements using the request form-, route-, and query string fields. After that, the model validates and attaches the given UserAccount instance to the database context and store its changes.

If the form used to HTTP POST these data fields does not contain a HTML checkbox to edit the IsAdmin field it is still possible to add a value for that field in either a form- or query-string field. Because the field is not present in any of the webpages that edit the user data, it is still possible for someone to find the field using other methods.

There are different ways to fix an overpost or mass-assignment issue. It is possible to instruct (with help of annotation attribute) the model binder to ignore certain fields when processing. The second approach is to separate the data model from the way the view delivers the data to the controller. You can use a view model for this solution.

BindAttribute Include Whitelist

In the first approach for fixing this problem, you annotate either the method argument userAccount or the class UserAccount with an instance of System.Web.Mvc.BindAttribute . The Include property of that attribute contains a comma separated list of properties that are included during binding. This approach is useful because that property newly added to UserAccount is not populated by default, and the developer has to explicitly add that name in the include list.

Below is the fixed code:

Below is a diff illustrating the changes:

NB: It is also possible to use the System.Web.Mvc.BindAttribute in combination with a blacklist property on that attribute called Exclude . However, this will not solve the problem if a new (internal only) field is added to UserAccount because it needs to be explicitly added to the blacklist to not be bound to any external untrusted data.

Separate ViewModel

The best approach is to fully separate the model that collects the data from the UserAccount that stores the data in the database. In the following code you see a ChangeUserViewModel that collects the data and mapped explicitly to the internal UserAccount instance that then stores the data. Any field you add to the model is not be exposed to the outside by default, so the developer should explicitly add the mapping in the processing logic to store that data element.

CWE  ↪

Ask the Community

• Web Application Penetration Testing
• Mobile Application Pentesting
• Web Services & API Assessment
• Threat Modeling
• Secure Code Review
• Application Architecture Review
• [Dynamic Posts]
• Network Vulnerability Assessment and Penetration Testing
• Device Security
• VoIP Vulnerability Assessment & Penetration Testing
• Wireless Penetration Testing
• Cloud Auditing
• Cloud Pentesting
• Red Team Assessment
• Dark Web Monitoring
• Ransomware Simulation
• Social Engineering Assessment
• Assumed Breach
• Smart Shore Sourcing
• Virtual CISO
• MANAGED SECURITY

Vulnerability Management as a Service

Vulnerability Remediation as a Service

Threat Intelligence as a Service

Strategic Security Solutions

• REGULATORY COMPLIANCE
• RBI Cyber Security Framework For Banks
• SEBI Cyber Security & Cyber Resilience Framework
• UIDAI – AUA KUA Compliance Security
• RBI Guidelines for Payment Aggregators & Payment Gateways
• RBI Cyber Security Framework For Urban Cooperative Banks
• RBI Guidelines for cyber security in the NBFC Sector
• SAR Audit for Data Localization
• STANDARD COMPLIANCE
• Hipaa Audit
• SOC2 Assessment
• Case Studies
• Whitepapers
• Journey Timeline
• timeline-image
• Mission,Vision, Values
• mission-vision-image
• Media title
• Media Image
• Partners title
• Partners Image
• Careers title
• Careers Image

HTTP Parameter Pollution and Mass Assignment Attacks

This blog focuses on two important things: the HTTP parameter pollution attack and mass assignment vulnerability. It helps developers to understand the risks that web apps can face and how to make them safer. The blog talks a lot about the need to check and control the information that goes into these apps. By doing this, it stops bad guys from getting in and changing things they shouldn’t. This blog gives helpful advice to make sure web apps are really secure. 

• HTTP Parameter Pollution
• Mass Assignment
• Best Practices

HTTP Parameter Pollution Attack 

HTTP Parameter Pollution (HPP) is a web application input validation vulnerability that occurs when an attacker appends the extra parameters in an HTTP request making confusing the web application and leading to unexpected behavior. This can potentially result in security issues such as bypassing security controls, accessing unauthorized data, or causing application malfunctions.

Using these characters in the input parameters could potentially perform a parameter pollution attack:

 / ? : @ & = + $ , ;\

Attack Scenario: 

• A web application that allows users to view their account details after logging in. The application takes a “user_id” parameter in the URL to fetch the user’s data from the server.
• URL for User Account Information: https://example.com/details?id=100
• An adversary will duplicate the id parameter and bypass the authorization checks from the server side and gains unauthorized access to view the details of other users’ accounts.\

• HPP can lead to the disclosure of sensitive information if the attacker manipulates parameters to access restricted resources or bypass authentication mechanisms. For example, if an application uses parameters to determine user privileges, an attacker could manipulate these parameters to access unauthorized data.
• HPP can also chain with other vulnerabilities, such as SQL injection or Cross-Site Scripting (XSS), to create more powerful and dangerous injection attacks.
• Attackers can use HPP to manipulate application logic and cause unintended actions or transactions, leading to financial loss or other undesired outcomes (https://example.com/transfer_amount?from=1234&to=5678&amount=9999&from=8686)

Mitigation:

• Validate and sanitize all user inputs on the server side. Ensure that only expected and valid characters are accepted.
• Ensure to implement that parameters are processed in the exact order they are received so the server can accurately interpret the intended values and prevent the pollution of parameter values. 
• Maintain a strict whitelist of allowed characters for each parameter to prevent unexpected input.
• Avoid using the same parameter name for different purposes within a single request to prevent parameter pollution.

Mass Assignment Vulnerability

Mass assignment is a process of assigning multiple values to object properties in a single operation. Mass assignment occurs due to flaws in the design or implementation of an application’s access control system. when an application allows users to easily update or create objects by automatically binding the data submitted in HTTP requests to the corresponding attributes or properties of the object. It allows unauthorized users to modify sensitive attributes or gain elevated privileges by manipulating the request parameters.

An additional parameter is added by guessing or based on parameters exposed in response. E.g. below.

“isAdmin”: true

“premium”: true

“banned”: false

The application uses the predefined parameter to define the access control of the user and these parameters are directly reflected in the response. Attackers can easily send those manipulated parameters with the request and can bypass the privileges.

Attack Scenario:

• The web application offers a registration feature through which users can create new accounts. During the registration process, it has been noticed that the response indicates “admin”: false.
• Due to a lack of input validation and authorization checks implemented, an adversary will add an additional parameter to the request “admin”: true and send the request to the server.
• By this an attacker can create an administrator account without proper authorization, potentially gaining unauthorized access to sensitive administrative functions and data.

• Attackers can manipulate the submitted data to modify or create objects with unauthorized attributes, potentially gaining access to sensitive data or functionality they shouldn’t have.
• By modifying attributes, attackers can elevate their privileges, granting them higher access levels or administrative capabilities.
• If sensitive attributes are negligently mass-assigned, attackers might extract or modify sensitive information that should not be accessible and allow them to modify user profiles, leading to unauthorized account takeovers.

Mitigation :

• Avoid functions that automatically bind a client’s input into code variables or internal objects.
• Use DTO_IN and DTO_OUT to whitelist only the properties that should be updated by the client.
• Blacklist properties that should not be accessed by clients.
• If applicable, explicitly define and enforce schemas for the input data payloads.
• using frameworks or libraries that provide built-in protections against mass assignment vulnerabilities can help mitigate the risk

Difference Between HTTP Parameter Pollution Attack and Mass Assignment Vulnerability :

In both cases, proper input validation, parameter handling, and access control mechanisms are essential to mitigate the associated security risks. Developers should carefully validate and sanitize user inputs and ensure that only authorized parameters are accepted and processed correctly.

References:

https://owasp.org/www-project-web-security-testing-guide/latest/4 Web_Application_Security_Testing/07-Input_Validation_Testing/04-Testing_for_HTTP_Parameter_Pollution

https://book.hacktricks.xyz/pentesting-web/parameter-pollution

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/20-Testing_for_Mass_Assignment

Conclusion:

In conclusion, this write-up has provided an exploration of the HTTP parameter pollution attack and mass assignment vulnerability. By understanding the importance of these security threats and their potential impacts on web applications.

The significance of implementing robust input validation and contextual escaping as fundamental defensive measures against these vulnerabilities has been highlighted. By incorporating these practices into their development processes, developers can reinforce the security of their applications and minimize the risks associated with unauthorized access and data manipulation.

Related Articles

Implementing a Cybersecurity Strategy in the Banking Sector

How To Implement Assume-Breach Security?

How Can Financial Services Combat the Threat of Cybercrime?

Leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Retail & eCommerce

Information Technology

Telecommunications

Application Security

Network Security

Cloud Security

Staffing Services

Threat simulation.

CERT-In Audit Services

Managed Security

Case studies

CERT-In New

White papers

Privacy Policy

WE ARE CERTIFIED

TRUST WE GAINED

© 2024 WeSecureApp. All rights reserved.

Download Now

Take a peek into sample report.

Get Started!

By failing to prepare, you are preparing to fail

Blog Write For Us

Subscribe to our podcasts, download your comprehensive guide to threat modeling today, fixed force, get cert-in audit.

Mass Assignment Vulnerability

What is Mass Assignment Vulnerability?

It is a computer vulnerability that involves abusing an active record pattern in a web application in order to modify data items that the user usually must not be allowed to access, including granted permissions, passwords, or administrator status.

In other words, to make developers’ work easier, the software framework allows developers to use mass assignment functionality i.e., it automatically binds HTTP request parameters either into program code variables or objects. This sometimes triggers the application into a vulnerable state.

This methodology might be used by attackers to create new parameters that were never intended by the developers. The parameters created by attackers might create or overwrite new variables or objects in program code that were not intended to receive in the request. This process of manipulating mass assignment functionality to access sensitive data or cause data loss is called the Mass Assignment vulnerability.

This vulnerability can have many alternative names depending on the language/framework being used:

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

Consider a form for editing the account information of a user, as shown below:

Image: An example of user form

• <form>
• <input name=”userid” type=”text”>
• <input name=”password” type=”text”>
• <input name=”email” text=”text”>
• <input type=”submit”>
• </form>

The form is binding to the following object:

• public class User {
• private String userid;
• private String password;
• private String email;
• private boolean isAdmin;
• //Getters & Setters

The following controller is handling the request:

• @RequestMapping(value = “/addUser”, method = RequestMethod.POST)
• public String submit(User user) {
• return “successPage”;

Here is the normal request:

• POST /addUser
• … // code
• userid=testuser&password=somepassword&email=test@ null user.com

Below is the exploit where the value of the attribute “isAdmin” of the instance of the class “User” is set:

• userid=testuser&password=somepassword&email=test@ null user.com &isAdmin=true

If the exploit is successful, then the “testuser” in the request will be granted with admin rights.

Exploitability of Mass Assignment Vulnerability

This functionality becomes exploitable in the following scenarios:

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

Impact of Mass Assignment Vulnerability

The successful exploit of mass assignment vulnerabilities provides the attacker to update object properties which should not be accessed by them, this in turn allows them to escalate privileges, modify data, and bypass security mechanisms.

Remediation

To prevent this, Rails (here the Rails framework is taken as a reference) offers two class methods in the Active Record class to control/limit access to your attributes; attr_protected (blacklist principle) and attr_accessible (whitelist principle).

• Ex: attr_protected :admin
• attr_protected :last_login, :as => :admin
• Ex: attr_accessible :name
• attr_accessible :name, :is_admin, :as => :admin

Utilizing mass assignment may make the work of developers easier but it will also help attackers exploit vulnerabilities. Hence, it is important for developers to use mass assignment carefully by considering all the security measures that help to keep the web apps secure.

References:

https://en.wikipedia.org/wiki/Mass_assignment_vulnerability

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

https://www.acunetix.com/vulnerabilities/web/rails-mass-assignment/

https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection

https://salt.security/blog/api6-2019-mass-assignment

Srikanth Rudrarapu,

Attack & PenTest Team,

Varutra Consulting Pvt. Ltd.

Related Posts

Open redirect.

WebSocket Vulnerabilities

“OAuth” Related Vulnerabilities

API6:2023 Unrestricted Access to Sensitive Business Flows

This threat has replaced Mass Assignment as number 6 on the OWASP API Security Top 10 list. It occurs when an API exposes a business flow without compensating for how the functionality could cause harm if used excessively through automation. In this new and prevalent type of API attack, business logic flaws are abused to allow malicious behavior.

To exploit this vulnerability, a bad actor will need to understand the business logic behind the API in question, find sensitive business flows and automate access to these flows in a way that can harm the business.

This issue usually stems from a lack of holistic view of an API. Understanding which business flow an API endpoint exposes and how sensitive that business flow is is essential in preventing this vulnerability. An API endpoint is vulnerable to this risk if it exposes a sensitive business flow, without appropriately restricting access to it.

Common examples of sensitive business flows and risk of excessive access associated with them include:

• An attacker can buy all the stock of a high-demand item at once and resell for a higher price.
• A bad actor can create a comment/post flow, spamming a company’s system.
• An attacker can reserve all the available slots for a given service and prevent other users from using the system.

This type of attack is notoriously hard to detect and protect against. Attacks in this category derive from a series of requests, in which each individual request is entirely legitimate. The attack can only be detected when looking at the sum of API requests in relation to the specific business logic context behind it.

API attacks that stem from Unrestricted Access to Sensitive Business Flows exploit business logic gaps across all business sectors, and each attack will be completely unique for each individual environment and each business logic.

Learn what it takes to secure APIs, how to evaluate API security offerings, and the capabilities needed to protect your business.

Potential impact of unrestricted access to sensitive business flows.

This type of attack is typically carried out by automated scripts or bots that exploit vulnerabilities or weaknesses in APIs. Some potential impacts of this category of API attack include:

• Service disruption by overloading the API infrastructure with a high volume of requests, leading to denial-of-service (DoS) or distributed denial-of-service (DDoS).
• Exhausting server resources like CPU, memory, or network bandwidth, negatively impacting the performance and availability of the API and the underlying systems.
• Unauthorized access and data breaches if attackers gain unauthorized access to sensitive data or user accounts.
• Account takeover (ATO) , if attackers target authentication and authorization APIs and are able to gain control of user accounts.

Real-life Examples:

Abusing an airline’s ticket system.

A good example of how an attacker could exploit an Unrestricted Access to Sensitive Business Flows vulnerability would be by booking 90% of the seats on a flight online, taking advantage of the fact that the airline would charge no cancellation fee.

The attacker could then cancel all tickets simultaneously at no expense just a few days before the flight date, forcing the airline to put the tickets back on sale at a discounted price in order to fill the flight. The malicious user would then be able to buy a ticket at a much cheaper price, benefitting from the discounted price and causing financial damage to the airline.

While this scenario didn’t make the news, sources close to us verify that it did indeed happen!

Why Existing Tools Fail to Protect You Against Unrestricted Access to Sensitive Business Flows

While WAFs and API gateways often include bot detection capabilities, automated API attacks targeting business logic flaws can employ evasion techniques to mimic human-like behavior, making it difficult to differentiate between legitimate users and malicious users. Additionally, these security controls rely on rules and signatures that won’t give them enough context to detect and block automated threats where attackers often employ sophisticated techniques to evade detection, rendering traditional security solutions ineffective.

How to Protect Your APIs Unrestricted Access to Sensitive Business Flows Attacks

In order to detect and stop this type of attack, an API security solution must be able to detect business logic flaws by analyzing all API traffic and establishing a baseline of typical API behavior over time. Only through this continuous analysis and using AI algorithms that are tested over a significant period of time, can the API security solution look at the sum of API requests and identify automated attacks that are unique to each API’s business logic and each individual environment.

To learn more about how Salt can help defend your organization from API risks, you can connect with a rep or schedule a personalized demo .

Salt Security Blog

Sign up for the Salt Newsletter for the latest resources and blog posts.

June 21, 2024

Don't Get Salted: Why API Inventory is Key to PCI DSS 4.0 Compliance (and How Salt Security Can Help You Achieve It)

A secure API ecosystem starts with a clear understanding of what APIs you have and how they interact with your data.

June 18, 2024

Increasing API Traffic, Proliferating Attack Activity and Lack of Maturity: Key Findings from Salt Security’s 2024 State of API Security Report

The latest Salt Security State of API Security Report is out now, and we’re thrilled to give a little sneak peek of its contents.

June 12, 2024

Salt Security Leading the Way in AI-Driven API Security for Next-Generation Threat Protection and Attacker Insights

Learn how the recent introduction of advanced LLM-driven attacker insights further solidifies Salt's position as a leader in API security solutions.

Download this guide for advice on evaluating key capabilities in API Security

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.

Special Features

Vendor voice.

If you're using Polyfill.io code on your site – like 100,000+ are – remove it immediately

Scripts turn sus after mysterious cdn swallows domain.

The polyfill.io domain is being used to infect more than 100,000 websites with malicious code after what's said to be a Chinese organization bought the domain earlier this year, researchers have said.

Multiple security firms sounded the alarm on Tuesday, warning organizations whose websites use any JavaScript code from the polyfill.io domain to immediately remove it.

The site offered polyfills – useful bits of JavaScript code that add functionality to older browsers that is built into newer versions. These in-fills make life easier for developers in that by using polyfillers, they know their web code will work across a greater range of browsers.

Now we're told polyfill.io is serving suspicious code hidden in those scripts, meaning anyone visiting a website using the domain will end up running potentially bad stuff in their browser.

"The cdn.polyfill.io domain is currently being used in a web supply chain attack," security monitoring biz c/side's Carlo D'Agnolo said in an advisory. "It used to host a service for adding JavaScript polyfills to websites, but is now inserting malicious code in scripts served to end-users." 

Additionally, we understand Google has started blocking Google Ads for websites that use the impacted code presumably to reduce traffic to them and cut the number of potential victims. Affected site owners have also been alerted by the internet giant.

"We detected a security issue recently that may affect websites using certain third-party libraries," a Google spokesperson told The Register . "To help potentially impacted advertisers secure their websites, we have been proactively sharing information on how to quickly mitigate the issue."

Sites that embed poisoned scripts from polyfill.io and also bootcss.com may end up unexpectedly redirecting visitors away from the intended location, and send them to undesirable sites, Google told advertisers.

More than 100,000 websites are already carrying the hostile scripts, according to the Sansec security forensics team, which on Tuesday claimed Funnull, a CDN operator believed to be Chinese that bought the polyfill.io domain and its associated GitHub account in February, has since been using the service in a supply chain attack.

Though Funnull claims to be based in Slovenia, and it says it has offices around the world, the listed addresses are nonsensical, the website's underlying language is Mandarin, it may actually be located in the Philippines, and there are other odd things about the organization, leading to folks suspecting the biz is actually Chinese in nature.

Polyfill.io is used by academic library JSTOR as well as Intuit, the World Economic Forum, and tons more.

Since February, "this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io," Sansec, an e-commerce security company, warned , adding that any complaints about the malicious activity are quickly vanished from the GitHub repository.

"The polyfill code is dynamically generated based on the HTTP headers, so multiple attack vectors are likely," Sansec noted, adding the code may, for example, redirect "mobile users to a sports betting site using a fake Google analytics domain."

• It may take decade to shore up software supply chain security, says infosec CEO
• What happens when the maintainer of a JS library downloaded 26m times a week goes to prison for killing someone with a motorbike? Core-js just found out
• Over 170K users caught up in poisoned Python package ruse
• In the rush to build AI apps, please, please don't leave security behind

In fact, Andrew Betts, who created the open source Polyfill project in the mid-2010s, told people earlier this year to not use polyfill.io at all. As we understand it, Betts maintained the project and contributed to its GitHub repo until a few years ago, arguing now that it's really no longer needed.

In February, he said he had nothing to do with the domain name and GitHub account's transfer to the mysterious CDN, and urged everyone to remove its code from their webpages as a precaution following the change in ownership.

"If you own a website, loading a script implies an incredible relationship of trust with that third party," he Xeeted at the time. "Do you actually trust them?"

Soon after CDN providers including Fastly , where Betts works today, and Cloudflare created mirrors of polyfill.io so that sites could continue to use the code for the meanwhile without having to load in stuff from a suspected Chinese entity.

"The concerns are that any website embedding a link to the original polyfill.io domain will now be relying on Funnull to maintain and secure the underlying project to avoid the risk of a supply chain attack," Cloudflare's Sven Sauleau and Michael Tremante said in February.

"Such an attack would occur if the underlying third party is compromised or alters the code being served to end users in nefarious ways, causing, by consequence, all websites using the tool to be compromised," they added.

Now that seems to be the case. ®

Editor's note: This article was updated to clarify and include further observations about Funnull. Also, check out our follow-up coverage here .

• Supply Chain

Narrower topics

• Advanced persistent threat
• Application Delivery Controller
• Authentication
• China Mobile
• China telecom
• China Unicom
• Common Vulnerability Scoring System
• Cybersecurity
• Cybersecurity and Infrastructure Security Agency
• Cybersecurity Information Sharing Act
• Cyberspace Administration of China
• Data Breach
• Data Protection
• Digital certificate
• Google Cloud Platform
• Google Nest
• Great Firewall
• Identity Theft
• Incident response
• Kenna Security
• Palo Alto Networks
• Privacy Sandbox
• Quantum key distribution
• Remote Access Trojan
• RSA Conference
• Semiconductor Manufacturing International Corporation
• Supply Chain Security Week
• Surveillance
• Tavis Ormandy
• Trusted Platform Module
• Uyghur Muslims
• Vulnerability

Broader topics

• Search Engine

Send us news

Other stories you might like

Google begs court for relief from epic games' play store demands, risk of installing dodgy extensions from chrome store way worse than google's letting on, study suggests, arm security defense shattered by speculative execution 95% of the time, are our it decisions costing the planet.

Microsoft answered Congress' questions on security. Now the White House needs to act

Google borrows from android to make chromeos better, google’s attempt to kill off child privacy app advertising lawsuit defeated, biden bans kaspersky: no more sales, updates in us, google cuts ties with entrust in chrome over trust issues, google festoons chrome enterprise browser with more controls, cisa looked at c/c++ projects and found a lot of c/c++ code. wanna redo any of it in rust, china's big tech companies taught asia to pay by scanning qr codes, but made a mess along the way.

• Advertise with us

Our Websites

• The Next Platform
• Blocks and Files

Your Privacy

• Cookies Policy
• Privacy Policy
• Ts & Cs

Copyright. All rights reserved © 1998–2024

• 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.

Mass Assignment: Insecure Binder Configuration (Fortify Error) after adding @JsonProperty Annotation

I am getting Mass Assignment: Insecure Binder Configuration in fortify analysis.

Here is the AuthorisationController.class

Here is the AuthorisationRequestInfo.class on which the http request params will be mapped.

The interesting thing is that I only started getting this error after adding the @JsonProperty("feedbackURI") annotation on the feedbackUri column.

@InitBinder was not being used before and there was no fortify error and all the parameters in the request are mandatory.

All other APIs are fine and do not report any fortify issues. Only this api and another one in which the @JsonProperty was added have started showing this error.

Any help would be appreciated.

• Do you save this feild in a DB ? If yes then do u have a mapper and entity . I faced similer issue , but in my code I am taking the same feild to the DB . \ I used then a JMapper to map it to a entity class and then save it to DB –  RaVin Commented May 13, 2019 at 2:17

You can use @JsonIgnoreProperties in your case:

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged spring-mvc fortify or ask your own question .

• Featured on Meta
• Upcoming sign-up experiments related to tags
• Policy: Generative AI (e.g., ChatGPT) is banned
• The [lib] tag is being burninated
• What makes a homepage useful for logged-in users

Hot Network Questions

• Trying to determine what this small glass-enclosed item is
• Is it unfair to retroactively excuse a student for absences?
• Folk stories and notions in mathematics that are likely false, inaccurate, apocryphal, or poorly founded?
• In By His Bootstraps (Heinlein) why is Hitler's name Schickelgruber?
• What is the relationship between gravitation, centripetal and centrifugal force on the Earth?
• Weird behavior by car insurance - is this legit?
• How does Mario Party Advance use my silliest secret?
• Is there any other reason to stockpile minerals aside preparing for war?
• Can I tell a MILP solver to prefer solutions with fewer fractions?
• Do IDE data lines need pull-up resistors?
• Were there engineers in airship nacelles, and why were they there?
• How many steps are needed to turn one "a" into 100,000 "a"s using only the three functions of "select all", "copy" and "paste"?
• DSP Puzzle: Advanced Signal Forensics
• Do capacitor packages make a difference in MLCCs?
• Is there a way to non-destructively test whether an Ethernet cable is pure copper or copper-clad aluminum (CCA)?
• Is Légal’s reported “psychological trick” considered fair play or unacceptable conduct under FIDE rules?
• How to produce this table: Probability datatable with multirow
• What does ‘a grade-hog’ mean?
• What is the original source of this Sigurimi logo?
• Why can Ethernet NICs bridge to VirtualBox and most Wi-Fi NICs don't?
• Rear shifter cable wont stay in anything but the highest gear
• Will feeblemind affect the original creature's body when it was cast on it while it was polymorphed and reverted to its original form afterwards?
• How do you say "living being" in Classical Latin?
• Why potential energy is not considered in the internal energy of diatomic molecules?