Parameter Manipulation attack on ASP.NET MVC web site

Most of the ASP.NET MVC web site security patterns I have seen are focused on stopping non-authenticated users from accessing the site, or non-authorised users from accessing methods.

These methods work really well to secure the site.

However, in developing an ASP.NET MVC web site I learned the hard way that the patterns in tutorial and training materials for ASP.NET MVC are prone to parameter manipulation attacks.

Luckily for me it was identified during a pen test, and could be fixed.

The problem is that most of the examples you see rely on passing record keys to methods. The user is authenticated, and is authorised to use the methods. The problem occurs when the user decides to manipulate the record keys - this calling a method with a record key that you did not provide them.

For example, if you have an EditUser method that accepts a user id as a key parameter. The method is called by a button on a page (say a search page), that posts the form with the key value in a field. The malicious user can save the web page to a local file, modify the key value, load the page into the current sessions browser window, and submit the form.

The anti-forgery token is valid, the user is valid, the user is authorised - however they are now viewing or editing a user they were not supposed to.

The ASP.NET MVC developer needs to be aware of this vulnerability, and re-check that the user has rights to the records they are viewing or editing when the parameters are returned.

This can be done by performing the authorisation check again, storing the valid values in session state, encrypting keys, or any other method you care to use, however you can not trust that the parameter has not been tampered with when you receive it!

BEWARE Reference variables in LINQ Lambda Expressions

I have come across a 'feature' of LINQ and lambda expressions where the variables used in the lambda are stored by reference, and changing them before you are finished with the result set cause the result set to change on the fly!

Now I am not across the inner workings of LINQ and lambda, however the results from doing the following code are not what I would have expected.

private void button1_Click(object sender, EventArgs e)
{
System.Diagnostics.Debug.WriteLine("Testing:" + DateTime.Now.ToString());
List<Dictionary<int, int>> ld = new List<Dictionary<int, int>>();

ld.Add(new Dictionary<int, int>() { { 1, 10 }, { 2, 20 }, { 3, 30 } });
ld.Add(new Dictionary<int, int>() { { 1, 20 }, { 2, 300000}, { 3, 40000000 }, { 4, 500000000 }});

int indx = 10;

var ds = ld.Where(itm => itm[1] == indx);

if (ds.Count() > 0)
{
System.Diagnostics.Debug.WriteLine("Count=" + ds.First().Count());
indx = ds.First()[2]; //this is a value I want to keep for later
int valueIwant = ds.First()[3]; //this is the value I want from this result

System.Diagnostics.Debug.WriteLine("Value I Want=" + valueIwant);
//oh no ??? that's not the value I wanted ???
System.Diagnostics.Debug.WriteLine("Count=" + ds.First().Count());
//and now the count changed ???
}

}

I would expect the LINQ query to return the first row, (where itm[key==1] == 10).

And valueIwant to equal the third value in that result dictionary (itm[key==3]).

The first count confirms we are working with row 1 with 3 records in the result dictionary.

HOWEVER, changing the indx value prior to getting valueIwant causes the result to change dynamically - thus returning a new result set, which in this case is row 2.

The end result in my variable is 40000000 - big diff. And the final count is 4, as it is the second record now.

This is a real trap - especially when using LINQ/lambda to work down a hierarchy of values.

My suggestion would be to use a pattern where any lambda expressions that use a variable should have the variable assigned to a lambda specific variable prior to creating the expression.

i.e.

int indx = 10;

int tmpidx = intidx;

var ds = ld.Where(itm => itm[1] == tmpidx);

if (ds.Count() > 0)

{

indx = ds.First()[2]; //this is a value I want to keep for later

int valueIwant = ds.First()[3]; //now I get what I wanted !!!!

I can't determine if this is by-design, a feature to support delegates, or a genuine bug, but it is definately something to watch out for!

Update: The legends on the MSDN forum suggest using .ToList() on the end of the Where statement to generate a fixed list result - thus separating the result set from the object query. It is also noted that each call to Count() and First() will cause the expression to re-evaluate!

http://social.msdn.microsoft.com/Forums/en-US/linqprojectgeneral/thread/b1480b00-44ec-4b32-984f-cdd53d87e99d