Hacking the new asp.net MVC RC1

I would love to sound clever, but this is a semi-well known hack in spring mvc framework.  My bosses boss, Willie Wheeler, mentioned it during a security conference we recently co-attended.  So, I thought to myself… why not check it out in MVC.net?  What I have found is that the same problem exists.

The basic idea of the hack is that when the view is rendered to the user it can sometimes be directly bound to an object.  Even if the view shown limits the fields that can be modified by the user, any public method on the object can be modified simply by updating the form values on the page with an intercept proxy.  This happens because the framework uses reflection on the form post variables to modify the edited object.

Lets say I have an object Foo.  Foo contains 3 properties that are public; bar (string), eggs (int) and notshown (int).  If I create an MVC controller and view (edit) which is directly bound to the Foo object I would write:

Public ActionResult Edit()

RenderView(new Foo());


To setup the new view, I can right click on the method and click on “Add view”.  Add view lets me bind a view directly to an object (In this case Foo) setup in an “Edit” mode.  The rendered view will, by default, show everything public on the object.  However, say I don’t want just anyone to edit the notshown property.   To “secure” this, I decide to only show eggs and bar and I remove notshown from the .aspx page.

The view that results will only show eggs and bar with input fields.

However, when the post back takes place, if I use a tool such as webscarab, or paros proxy, or fiddler (etc…), I can insert a post value of notshown and set it’s value to -1 or any int.  Even though the field is not public to the website, it can still be modified. It’s very easy to setup a mock for this, and if anyone is interested I can send them the one I have.

While this hack does presume that the hacker knows what is on the class, there are some ways to make informed guesses about what is there and what isn’t.  For instance, lots of classes store an instance of the requesting userid….. why couldn’t that be set to a new value?  Sites like e-commerce could use price or even Id as a property.  This could be also potentially be used as a way to escalate privileges if need me.

There is however great news.  Microsoft is already fully aware of this. The even have provided for you a method to whitelist the methods you are willing to support. In the Post response to your page, you can add:

UpdateModel(someFoo, new [] { “bar”, “eggs” });

This will limit the forms value explicitly to the bar and egg properties on eggs.  However, if you do not directly do this, the hack is available for your site.  In short, if you are using MVC and you bind a view to an object… you should white list the response variables.

Just something that popped up, thought I would mention here as well.


Post a comment or leave a trackback: Trackback URL.


  • By ASP.NET MVC Archived Blog Posts, Page 1 on February 2, 2009 at 3:55 am

    […] to VoteHacking the new asp.net MVC RC1 (1/29/2009)Thursday, January 29, 2009 from pinvokeI would love to sound clever, but this is a semi-well known […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: