Hidden field integrity: Asp.NET mvc

Question

we use asp.net mvc for development. sometimes we need to put some hidden fields in the form that are popped into the model using modelbinder (as expected). Now users can easily smooth out a form using firebug or other utilities. The purpose of the hidden field is mainly to provide some information to the server as a basis, and they are not intended to be modified. For example, in my employee edit form, I can put EmployeeID in a hidden field, but if the user changes the employeeID in the hidden field, the wrong employee will be updated in the database. in this scenario, how can we maintain the integrity of hidden fields
welcome

Answer 1

You need to ensure safety to ensure that the person performing the modification has permission to do so. I would also put the identifier in the URL, as a rule, rather than a hidden field, relying on security to ensure that people do not change what they should not be able to. If they have permission to change the item when changing the identifier manually, this should not be a problem. It is important to make sure that the person cannot manually change the identifier and gain access to what they do not need. Forced server permissions resolve this issue. You can easily do this with Roles in combination with AuthorizeAttribute.

Answer 2

if the user changes the employeeID to a hidden field, the wrong employee will be updated in the database

This is a serious security hole on your website. In everything you do with web development, no matter how smart some kind of code can be or how much you think you'll be fine as long as users don’t do anything, remember one golden rule: never imply data trust received from the customer.

To change anything on his website, the user must be logged in. (Is that right?) Therefore, in any attempt, the user makes to submit the form to the website (especially the one that can modify the data), double check that the user submitting the form has permission to perform the requested action on the specified data.

Ideally, every action that is not fully public and unsecured should have a server-side rights check. Never, never trust what the customer sends you.

Answer 3

One possible alternative would be to store this static one-time information in TempData on the server and not pass it to the client where it could be faked. Keep in mind that TempData uses Session by default and has its own limitations, but this may be an option.