.NET Remediation Guidance for CWE-915

Why do you detect it?

Attackers will often try to manipulate HTTP requests in such a way in attempt to bypass business logic, such as setting a flag on a model that was not intended to be accessible by an end-user. This can occur in ASP.NET MVC and API applications due to model binding that automatically maps HTTP parameters to a model specified on the controller’s action. If the action did not intend for all model properties to be used, an attacker could still craft a request parameter that maps to one of the unintended model properties. The parameter and the value would bind automatically introducing unintended behavior within the application. This type of flaw is commonly referred to as an overpost attack.

How does Veracode Static Engine detect flaws of this type?

In general Veracode Static Analysis finds this flaw as follows:
  1. The analysis searches your binaries for controller action methods.
  2. The analysis then checks if the model in the action is annotated with the BindAttribute.
  3. The scanner detects the BindAttribute sets the Include property and explicitly specifies the model properties that are accessible, otherwise it will open a flaw.

How can I fix it and have the Veracode Static Engine automatically detect my fix?

We will first look at a strategy that the Veracode Static Engine will detect, then we will see strategies that reduce risk but require mitigation.

Annotate Action Model Parameter with Bind Attribute and Include Property

The only recognized code remediation of this flaw requires that the controller action’s model parameter be annotated by the System.Web.Mvc.BindAttribute and requires the specification of the Include property.
For more information on the BindAttribute, please refer to MSDN’s documentation: https://docs.microsoft.com/en-us/dotnet/api/system.web.mvc.bindattribute?view=aspnet-mvc-5.2

As an example, assume we have the following model:
 
public class User
{
    [Key]
    public Guid Id { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
    public string Email { get; set; }
    public bool IsAdmin { get; set; }
}

And that we have the following form:
 
<form action="/Users/UpdateEmail ">
    Update your Email: <br/>
    Email: <input type="text" name="Email" /> <br/>

    <!--
        Don't use hidden fields for object references unless you have server side
        validation to ensure permissions to update the referenced object. This is
        for simple demonstration purposes. This would be categorized as CWE-639.
  -->
    <input type="hidden" name="Id" value="42" />
    <input type="submit" />
</form>

And that we have the following controller action:
 
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult UpdateEmail(User user)
{
    if (ModelState.IsValid)
  {
         db.Users.Update(user);
         db.SaveChanges();
         return RedirectToAction("Index");
  }

     return View(user);
}

The above code would allow an attacker to craft a custom built request to the “/Users/UpdateEmail” route that includes an  IsAdmin request parameter which would automatically bind to the model’s corresponding property. An attacker in this instance could set the property to true to escalate privileges to admin even though the intent of the endpoint was to simply update the user’s email.

To remediate this example, it is possible to update the controller action’s signature to include the BindAttribute on the model parameter specifying the Include property. See:
 
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Update([Bind(Include="Id, Email")] User user)
{

This would restrict ASP.NET to only bind the Id and Email request parameters to the model using a whitelist approach and as such the flaw will be seen as fixed by the Veracode scanner.

How can I mitigate the risk?

The following strategies reduce risk that the Veracode Static Engine cannot detect. These strategies require that mitigations be documented for the flaw to no longer impact policy. For more information on mitigations, see “Mitigating Flaws”: https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/~p4MSKOS8F8X8h0KwFTKoQ 
 

Annotate Action Model Parameter with Bind Attribute and Exclude Property

In some instances a whitelist approach may not be suitable for the implementation but rather a blacklist approach is called for. In such instances, the scanner will not detect the flaw as fixed and will continue to report the flaw. This type of remediation requires a mitigation to state the controls added to reduce risk. This approach is not recommended because for example consider future iterations of the model class that may add more properties and as such the BindAttribute Exclude property would need to be updated to exclude any unwanted or dangerous properties.
 

Use Pure ViewModel without Direct Modification in Data Access Layer

Another solution is to consider a design pattern that does not directly update the database entity. A ViewModel that is explicitly scoped to only the required data for the action that is then mapped to a database entity in an abstraction layer reduces the risk of overposting. This remediation approach requires mitigation.
 

Topics (3)

Related Articles

Related Topics

    Ask the Community

    Get answers, share a use case, discuss your favorite features, or get input from the Community.