Prevent change of hidden field

Question

What if I have ChangePassword form with hidden ID field of the user.

BadPerson knows id of GoodPerson. He opens Change Password form with FireBug, changes his Id to GoodPerson's Id, so password changes for GoodPerson.

Of course I can create some server logic that will prevent this, but I think there should be some out of the box solution, which throws if hidden field been changed, which I don't know.

EDIT Ok, Change Password is a bad example. Any edit form where I have id in hidden field has same problem.

Answer 1

I agree with Darin that forms authentication will take care of the specific problem mentioned above (changing a password). This answer is for the more general question of making sure that a hidden field's value is not changed.

The best solution to this is to include another hidden field which contains a hash of the first hidden field's value. That way if the 1st hidden field is changed you will know it. The generated HTML looks something like this:

<input id="productId" name="productId" type="hidden" value="1" />
<input id="productId_sha1" name="productId_sha1" type="hidden" value="vMrgoclb/K+6EQ+6FK9K69V2vkQ=" />

This article shows how to do it and includes source code for an extension Html.SecuredHiddenField which will take care of the logic for you.

Answer 2

There is nothing that will let you know that a value of a hidden field's value has been changed or not. For a user to change his password it means that he needs to be authenticated. When using forms authentication the ID of the currently authenticated user is stored in an encrypted cookie which cannot be modified.

This is to say that you shouldn't use hidden fields for storing the currently connected user. Just use the built-in FormsAuthentication mechanism in ASP.NET and never store such information in hidden fields. The way ASP.NET knows that the value of the cookie hasn't been tampered with is that it signs it with the machineKey specified in the configuration.

There's an important rule that you should follow when dealing with security and authentication: always use built-in security mechanisms, never roll your own.