Mass Assignment vulnerability and prevention

Tram Ho

Introduce the flaw

When developing software, developers often use pre-built frameworks for development. This is both convenient and minimizes the time and effort of building up from scratch. These frameworks have been developed with security features in place to help ensure the security of the application being developed. But sometimes improper use or misuse causes serious vulnerabilities.

Some web development frameworks (e.g. Laravel, Ruby on Rails, ..), for development convenience, it allows the developer to automatically push parameters via HTTP requests into program variables or arguments. statue. From there, the program will take and process data on the server. This sometimes causes problems and security. An attacker can take advantage of this to insert malicious data that are parameters of the program (these parameters are not allowed or transmitted by developers) to execute the undesirable behavior. This security vulnerability is known as Mass Assigment.

Some other names for this attack:

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

How to attack

To better understand how to attack, let’s go through a few examples to better understand this security vulnerability.

Example 1: Create a new user in the system

User has the following fields of information:

The programmer creates a new user creation form as follows:

Here, the developer designed to allow users to update 3 fields: userid, password và email The processing of the controller will be done as follows:

And a normal reuqest posted would look like this:

As usual, after the POST request is submitted, the application will read and retrieve the data and insert into the database. A user is created with the following information:

A normal flow of work and of course here, the developer has completed the task of feature development and it runs completely fine.

So how can the above application be hacked? The problem here is that in the controller processing, the developer has inadvertently created an opportunity for the attacker to perform the attack. As we can see, the user has 4 fields of information and the developer develops a feature that allows the creation of a user with the above 3 fields (not including the: isAdmin field) because this field is an important field that defines the role of the user and should only be updated by the system admin. But controller, developer process to receive all user parameters passed without checking which parameters are allowed or not?

So the hacker will perform the attack by passing more parameters in the request to create a new user:

After the POST request is sent, the application will perform read and retrieve data and perform insert into the database. A user is created with the following information:

So attacker can create a user as admin account. Obviously this was not by design and caused a critical vulnerability, allowing a highly privileged account to be created in the system.

So we understand how this vulnerability attacks. But there is one more problem here, is how an attacker can guess that the user has the isAdmin information isAdmin to perform the attack. There are several ways that an attacker can find it.

  • Through the function of viewing user information, updating user information attacker can see the fields that the user has
  • Through the review of the sourcode and documentation of the system
  • Through guessing technique to guess some sensitive information field. (Example: isAdmin, admin, isAthenticated ..)


The consequences of this vulnerability depend on the function and the field that an attacker can attack. It can cause several types of attacks:

  • Privilege escalation attacks in the system
  • Attacks unauthorized modification of information in the system


Depending on the framework we use, we have different behavior, but it all will follow the same mechanism:

  • Whitelist fields are allowed to bind
  • Blacklist fields are not allowed to bind
  • Use Data Transfer Objects ( refer here ). DTO defines exactly what fields are allowed to bind:

Some examples of implementation with frameworks

Spring MVC



PHP Laravel



See more frameworks here

Case study

Github: Public Key Security Vulnerability and Mitigation

In 2012, Github was exposed to a Mass Assigment vulnerability. A hacker exploited the vulnerability through the public key update form to be able to add his public key and rails organization, from which he could access the github of this organization and push the file up as he pleased.

During security testing, I also encountered many applications that encountered the above error. The application still allows updating information fields that are not allowed. So, right now, developers need to review to see if they have done as recommended by the frameworks to avoid this vulnerability.

Share the news now

Source : Viblo