3

If I have an HTML form, and it has hidden inputs for ID numbers and the like (so I know the id key of of table x to update), how can I secure it so the person can't just change it and screw up database entries?

I have a modal bootstrap "popup," for example, that I append hidden inputs to the form so when I submit the form in the modal the correct database keys are submitted and processed.

Someone can easily change that (not to mention editing the Header and Resend). What can I do? The site is secured with username and password, but other than that I am not sure what to do. I'm not as worried about SQL Injection as much as bad data.

The only other thing I could think is to store values in Session Variables.

I am using ASP.NET Core 2.x and jQuery if it matters.

This was similar, Protecting hidden form fields

7
  • It sounds to me like you're trying to solve the wrong problem. If someone is allowed to modify a table, why not let them? If someone isn't allowed to modify a table, then you need to have permission checks to prevent them. Read the accepted answer to the question you linked. Commented Mar 28, 2018 at 15:40
  • It's not that. The user is. I'm asking what if the person using the web application modifies the form data.
    – johnny
    Commented Mar 28, 2018 at 15:42
  • Then just let them? It's not like they're going to accidentally modify a hidden field. Commented Mar 28, 2018 at 15:52
  • 1
    So let them modify a hidden field and change keys around so my data is not associated correctly in the database? No.
    – johnny
    Commented Mar 28, 2018 at 15:55
  • you need to validate the every user data on the server-side.
    – elsadek
    Commented Mar 28, 2018 at 15:55

2 Answers 2

11

You don't. User can change whatever they want to. A hidden field is not different from a common field from the browser or server perspective.

If you want to store secret data the user will need, store them server-side on a session. It's the fastest way.

2

You can use HMAC or some other digital signature mechanism, such as encrypting the "hidden" data with the page-and-user-specific encryption key, and then decrypting and validating it on the server side after submission. This would allow your application to detect such modifications, whether they were done by the user or by something else, like field-modifying bugs in Javascript.

At least one framework is doing this, by storing its full state in JSON form (encrypted and base64) in hidden fields.

The main - and only - advantage here over simply storing the associated data server-side is reduced storage needs on the server side - in this case all you need to store is the encryption key for the current state.

To be secure, the encryption key should be generated for each use (i.e. each page and each user). Otherwise a malicious user would be able to move around your hidden fields between different pages (and different users), exploiting your logic even without knowing the actual raw values.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .