I have a question related to security and manipulating the parameters of controls during a postback. The very contrived example below explains it.

I have a business object which has the following properties:

- ID
- AddedBy

In an aspx page, I have a delete button. In the 'OnClick' event I call a BLL method which deletes this object from my underlying datastore. The 'delete' method just takes a single parameter, that being the 'ID' for the object.

However, only the user who created the object should be allowed to delete it. Depending on the currently logged on user, in PageLoad the 'CommandArgument' of the Delete button is being set to the appropriate ID value. I then retrieve the CommandArgument value in the 'OnClick' event for passing to the BLL delete method.

For example:

- User 'foo' has already created an object. It is given ID of 24 and AddedBy of 'foo'.
- User 'foo' logs on and goes to the 'delete object' page.
- In PageLoad, the logged on Username is used to retrieve the correct object, using a method created for this called  'GetObjectByUsername'.
- Also in PageLoad, the CommandArgument of the 'Delete' button is set to the ID of the retrieved object. In this case the CommandArgument is set to 24.
- When user 'foo' clicks on the 'Delete' button, the OnClick event is fired, whereby the ID parameter of the 'delete' method is passed the value 24. The object is deleted.

Now, this is all well and good. But how secure is it? Would it be possible to use an HTTP proxy tool such as Fiddler to replace the value 24 with the value 25, thereby deleting the wrong object?

A way to prevent this would be to do a security check. In the Delete method, first check that the object in question really was added by the currently logged on user.
For example, use something like:

MyObject myObject = GetObjectByID(24);
if (Page.User.Identity.Name == myObject.AddedBy)
 { go ahead and delete the object }
else
 { give the user an appropriate error message }

Or, cache the ID from the object retrieved in PageLoad in a private page variable, and check against this before calling the 'delete' method.

However, doing any of this incurs overhead.

So, are these sorts of checks necessary? Or, by doing them, am I wasting server resources?

Any thoughts much appreciated.

Holf:

Now, this is all well and good. But how secure is it? Would it be possible to use an HTTP proxy tool such as Fiddler to replace the value 24 with the value 25, thereby deleting the wrong object?

A way to prevent this would be to do a security check. In the Delete method, first check that the object in question really was added by the currently logged on user.
For example, use something like:

MyObject myObject = GetObjectByID(24);
if (Page.User.Identity.Name == myObject.AddedBy)
 { go ahead and delete the object }
else
 { give the user an appropriate error message }

Hi

By default, a event validation mechanism will reduces the risk of unauthorized postback requests and callbacks. It is strongly recommended that you do not disable it.

http://msdn2.microsoft.com/en-us/library/system.web.ui.page.enableeventvalidation.aspx

Holf:

- When user 'foo' clicks on the 'Delete' button, the OnClick event is fired, whereby the ID parameter of the 'delete' method is passed the value 24. The object is deleted. 

But a server side check is still necessary, One scenario I think might happen is:

If there are more than one people working on same page, this may cause a synchronization problem and you need to check the current state when user performs the action..

Hi, and thanks for the reply.

Yes, I am definitely keeping EventValidation on. Indeed, there are instances where I have had to register additional client-script for postback (such as when making the row of a GridView clickable).

However, EventValidation alone would not stop a user substituting different values into a valid paramenter. So it looks as though Server side checks are necessary in this sort of case.

Holf:

Would it be possible to use an HTTP proxy tool such as Fiddler to replace the value 24 with the value 25, thereby deleting the wrong object?

Yes.  I know this because my app (a rather sensitive app used to wire money) was on the receiving end of a security audit and we got nailed on this issue.  It was an embarassing moment when they showed us how easily this kind of thing can be done.  I learned a lot.

A solution is to pass things around in Session instead since that keeps everything on the server.  If your parameters are passed in the URL you can also include a hash to check whether the values have been tampered with (of course, you'll need to pass the hash key around in Session).