Mass Assignment

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

Example

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

<form>
     <input name="userId" type="text">
     <input name="password" type="text">
     <input name="email" text="text">
     <input type="submit">
</form>

Here is the object that the form is binding to:

@Data
public class User {
   private String userid;
   private String password;
   private String email;
   private boolean isAdmin;
}

Here is the controller handling the request:

@RequestMapping(value = "/addUser", method = RequestMethod.POST)
public String submit(User user) {
   userService.add(user);
   return "successPage";
}

Here is the typical request:

POST /addUser
...
userid=attacker&password=s3cret_pass&email=[e-mail]

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

POST /addUser
...
userid=attacker&password=s3cret_pass&email=[e-mail]&isAdmin=True

References

• OWASP Mass Assignment Cheat Sheet
• Spring MVC, protect yourself from Mass Assignment
• Security of your application and frameworks: the attack on GitHub
• Write up: Spring's setDisallowedFields bypass in the VolgaCTF2019 Shop task
• Write up: The VolgaCTF2019 Shop v2 task