In my article on Parameter Tampering in ASP.NET MVC I focused on the general techniques of parameter tampering and defenses against it. In this article I will examine a specific type of parameter tampering which is often termed Mass Assignment.
In most MVC web development frameworks (including ASP.NET MVC). Model binding works by assigning an incoming html Form’s values to an object’s properties. This makes for very efficient development but one that contains a critical security flaw.
Take the below Employee model:
public class Employee
{
public int ID {get; set;}
public string FullName {get; set;}
public DateTime DateOfBirth {get; set;}
public bool IsAdmin {get; set;}
}
Note for now that the IsAdmin property is for determining if the Employee has admin rights on the application.
Assuming an employee creates a record themselves in the web app the relevant part of the html form will be as below (note that the id field is automatically set when the record is created in the database and so is not present and the IsAdmin field is not exposed).
<input id="fullname" name="fullname" type="text" > <input id="dateofbirth" name="dateofbirth" type="text" >
When the form is submitted it will produce the below Http Post Request:
Request URL:http://yoursite/register Request Method:POST Status Code:200 OK ... ... fullname:Jude OKelly dateofbirth:22-04-1972
In an MVC framework like ASP.NET MVC an incoming Http Post/Get request is handled by a Controller’s method. In the scenario of a form being posted to the server, the MVC framework can automatically create an object and populate its properties with the form values:
[HttpPost]
public ActionResult Register(Employee emp)
{
//the emp object is automatically created and assigned the values from the html form:
db.Employees.Add(emp);
db.SaveChanges();
}
The above example uses an ORM such as Entity Framework to save the emp object to the database. So the database will contain the posted values for FullName and DateofBirth. The ID property is automatically assigned and since the IsAdmin value is not provided it is given a default value of False. Thus, in this case the newly created user will not have admin rights on the system.
However, using a tool such as Fiddler it is relatively simple to alter the html Post to include ‘IsAdmin:True’:
Request URL:http://yoursite/register Request Method:POST Status Code:200 OK ... ... fullname:Jude OKelly dateofbirth:22-04-1972 isadmin:true
Once the ASP.NET MVC model binder receives this http post request it will attempt to match as many properties of the incoming form with the Employee object, since the IsAdmin property is now provided it will be set and saved to the database. Thus the new user will now have full admin rights to the system.
Another way to inject ‘IsAdmin=true’ would be to simply add it to the querystring when posting back the page. ASP.NET MVC (as well as other MVC frameworks) will look for model values in the html form values, the querystring and route values, and cookies.
Solutions
There are several solutions to this vulnerability:
Matching Incoming Parameters
Instead of using a full object in the method’s constructor, just declare the parameters that are expected and manually bind them to the Employee object:
[HttpPost]
public ActionResult Register(string fullName, DateTime dateOfBirth)
{
var emp = new Employee{FullName = fullName, DateOfBirth=dateOfBirth};
db.Employees.Add(emp);
db.SaveChanges();
}
In this case that any additional data such as IsAdmin=True in the form post will be ignored and not make it into the database.
Use A ViewModel
A very common practise in MVC web development is to create custom models for each page (or ‘View’ in MVC parlance). These models can be a composite of different domain models or just a subset of properties of a single domain model.
In this case we would simply declare a ViewModel as below:
public class RegisterEmployeeViewModel
{
public string FullName {get; set;}
public DateTime DateOfBirth {get; set;}
}
Note this ViewModel only contains the two properties of the Employee object we wish to receive from the html form.
Now in the Controller we will receive this model and use the MVC model binder to automatically create the RegisterEmployeeViewModel object and populate its properties with the values of the html form:
[HttpPost]
public ActionResult Register(RegisterEmployeeViewModel empViewModel)
{
var emp = new Employee{FullName = empViewModel.FullName,
DateOfBirth= empViewModel.DateOfBirth};
db.Employees.Add(emp);
db.SaveChanges();
}
In this case we created a new Employee object and populated is values with the ViewModel object’s properties, in practice various mapping solutions can do this automatically to simplify the process.
Whitelist / Blacklist Parameters To Bind
ASP.NET MVC provides the Bind attribute which can be used to either specifically include or exclude parameters for model binding.
Whitelist parameters to be included in model binding (note only the UserName will be used in binding) :
[HttpPost]
[Authorize]
ActionResult UserDetails([Bind(Include = "UserName")] User user)
{
//Update Logic
}
Blacklist parameters to be excluded in model binding (all parameters except IsAdmin will be used in binding) :
[HttpPost]
[Authorize]
ActionResult UserDetails([Bind(Exclude = "IsAdmin")] User user)
{
//Update Logic
}
This approach has the weakness that it requires the Bind attribute to be used on every controller action where a mass assignment model binding vulnerability may exist, which is a reliable approach – a new controller action could easily be added in an update which omits the crucial bind attribute. In general this defense should be thought of as an extra layer of security to be used in conjunction with other approaches.
Unfortunately, so many of the early demos of ASP.NET MVC featured this simplified model binding scenario that the security flaw is very common in production sites (or at least that is my experience).