CODEWITHSUNDEEP
asp.net-mvcsecuritymodel-binding
makerofthings7
makerofthings7

Reputation: 61473

How can I detect an overposting attack in ASP.MVC during model binding?

I want to determine if a user is attempting an overposting attack in Asp.NET MVC.

How can I determine if someone is sending special values (via Fiddler for example) to my controller?

Note the "bind" attribute below

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create([Bind(Include = "LastName, FirstMidName, EnrollmentDate")]Student student)
{
    try
    {
        if (ModelState.IsValid)
        {
            db.Students.Add(student);
            db.SaveChanges();
            return RedirectToAction("Index");
        }
    }
    catch (DataException /* dex */)
    {
        //Log the error (uncomment dex variable name and add a line here to write a log.
        ModelState.AddModelError("", "Unable to save changes. Try again, and if the problem persists see your system administrator.");
    }
    return View(student);
}

The Bind attribute is one way to protect against over-posting in create scenarios. For example, suppose the Student entity includes a Secret property that you don't want this web page to set.

   public class Student
   {
      public int ID { get; set; }
      public string LastName { get; set; }
      public string FirstMidName { get; set; }
      public DateTime EnrollmentDate { get; set; }
      public string Secret { get; set; }

      public virtual ICollection<Enrollment> Enrollments { get; set; }
   }

Even if you don't have a Secret field on the web page, a hacker could use a tool such as fiddler, or write some JavaScript, to post a Secret form value. Without the Bind attribute limiting the fields that the model binder uses when it creates a Student instance, the model binder would pick up that Secret form value and use it to create the Student entity instance. Then whatever value the hacker specified for the Secret form field would be updated in your database. The following image shows the fiddler tool adding the Secret field (with the value "OverPost") to the posted form values.

Upvotes: 4

Views: 4608

Answers (3)

Owen
Owen

Reputation: 76

Personally I wouldn't bother logging everything coming in, you're just gonna fill up your logs with junk (albeit if the logging is configured for only errors that wouldn't matter). The only benefit you're going to get is someone tried, failed, and that's it. You can't do much. You could block IP addresses but domestic ISP's assign different IP's all the time, so you might end up blocking a legitimate user next time that IP gets assigned to someone else.

Like @DevTekVE mentioned, another way would be to have some middleware on controllers to log such things to avoid repetitive code, but I go back to my point made above.

Upvotes: 0

DevTekVE
DevTekVE

Reputation: 193

It might be too late, but still, I have a recommendation for the intended purpose.

The way you currently have your controller set, you will never be exposed to such attack, but you could try to get a hold of the raw POST data sent to you with (Reference)

HttpContext.Current.Request.InputStream.Position = 0;
var result = new System.IO.StreamReader(HttpContext.Current.Request.InputStream).ReadToEnd();

and then parse it yourself just solely for logging purposes and check if it received more parameters than expected or malformed parameters.

I totally understand and agree your point, I am constantly analyzing for security breaches. But does it really worth the impact on the performance for a vector that is closed? Based on my experience, you will not be able to flag any IP, as we can use VPN's to get around it, or even TOR.

Upvotes: 1

Darin Dimitrov
Darin Dimitrov

Reputation: 1039248

If you use view models then overposting wouldn't be any issue for you and not something that you should be concerned about. The reason for that is that you will include only the properties that are supposed to be coming from the user input in your view model. Then you will fetch the actual entity from your database and merge both. This way all sensible properties of the entity will remain untouched. So as a rule of thumb: always use view models in an ASP.NET MVC application - all your POST controller actions that are supposed to modify some state on the server should take a view model, not an entity model.

So instead of trying to determine if someone is trying to overpost some values that he is not supposed to modify, you could simply forbid this by allowing him to modify only the values that he is supposed to - by exposing them in a view model.

Upvotes: 9

Related Questions