This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Mass Assignment Cheat Sheet"

From OWASP
Jump to: navigation, search
m
Line 8: Line 8:
  
 
= Introduction =
 
= Introduction =
Put good stuff here!
+
"Modern frameworks allow developers to automatically bind HTTP request parameters from both request query and body into model objects for ease of development and increased productivity. If the binder is not correctly configured to control which HTTP request parameters are bound to which model attributes, an attacker may be able to abuse the model binding process and set any other attributes that should not be exposed to user control. This binding is possible even if the model attributes do not appear in the web forms or API contracts." - [http://www.hpenterprisesecurity.com/vulncat/en/vulncat/java/mass_assignment_sensitive_field_exposure.html Mass Assignment: Sensitive Field Exposure]
 +
 
 +
=== 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:
 +
 
 +
  public class User {
 +
      private String userid;
 +
      private String password;
 +
      private String email;
 +
      private boolean isAdmin;
 +
   
 +
      //Getters & Setters
 +
    }
 +
 
 +
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=bobbytables&password=hashedpass&[email protected]
 +
 
 +
And here is the exploit:
 +
 
 +
  POST /addUser
 +
 
 +
  userid=bobbytables&password=hashedpass&[email protected]&isAdmin=true
 +
 
 +
 
 +
The attacker can exploit this if:
 +
* They can guess common sensitive fields
 +
* They have access to source code and review the models for sensitive fields
 +
 
 +
=== General Solutions ===
 +
* Whitelist the bindable, non-sensitive fields
 +
* Blacklist the non-bindable, sensitive fields
 +
* Use Data Transfer Objects (DTOs)
 +
 
 +
=== Alternative Names ===
 +
Depending on the language/framework in question, this vulnerability can have several [https://cwe.mitre.org/data/definitions/915.html alternative names]
 +
* Mass Assignment: Ruby on Rails, NodeJS
 +
* Autobinding: Spring MVC, ASP.NET MVC
 +
* Object injection: PHP
 +
 
 +
 
 +
= Languages & Frameworks =
 +
 
 +
== Spring MVC ==
 +
 
 +
== NodeJS ==
 +
 
 +
== Ruby On Rails ==
 +
 
 +
== Django ==
 +
 
 +
== ASP.NET ==
 +
 
 +
== PHP Laravel ==
 +
 
  
 
= Authors and Primary Editors =
 
= Authors and Primary Editors =

Revision as of 22:58, 17 February 2016

Cheatsheets-header.jpg

Last revision (mm/dd/yy): 02/17/2016

Introduction

"Modern frameworks allow developers to automatically bind HTTP request parameters from both request query and body into model objects for ease of development and increased productivity. If the binder is not correctly configured to control which HTTP request parameters are bound to which model attributes, an attacker may be able to abuse the model binding process and set any other attributes that should not be exposed to user control. This binding is possible even if the model attributes do not appear in the web forms or API contracts." - Mass Assignment: Sensitive Field Exposure

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:

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

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=bobbytables&password=hashedpass&[email protected]

And here is the exploit:

  POST /addUser
  
  userid=bobbytables&password=hashedpass&[email protected]&isAdmin=true


The attacker can exploit this if:

  • They can guess common sensitive fields
  • They have access to source code and review the models for sensitive fields

General Solutions

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

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


Languages & Frameworks

Spring MVC

NodeJS

Ruby On Rails

Django

ASP.NET

PHP Laravel

Authors and Primary Editors

References and future reading

Other Cheatsheets