Preventing users from tampering with input

Question

Let's say that I have a single-page web app written in JavaScript and a server-side API, both changeable by me. The app calculates some values based on user input and POSTs these to the API. The values are based on user input but do not contain user input. For instance it might ask the user to pick A or B based on radio buttons, then send their choice to the server. There is no session, and the user is anonymous.

Rule #1 is Never Trust User Input. A malicious user could modify the payload, and change "A" to "C" (not one of the choices). I don't want that to happen.

For simple cases there is an obvious solution: validate the input server-side. If it's not "A" or "B", reject it. In a complex app, though, the number of possible permutations could make validation very difficult.

The app could digitally sign the calculated payload before sending it, but as the JavaScript is available to the client, a user could obtain both the key and the algorithm. Obfuscation isn't sufficient here.

Has anyone come up with any way to prevent this sort of tampering? Time-based keys provided by the server? Web3? Or is there a formal proof that it is impossible (aside from server-side validation against a set of input constraints)?

Answer 1

TL,DR: It's impossible to do so client side.

Client side validation is just a client convenience, not useful to really validate anything. You don't want the client to mistype his email, putting an invalid char somewhere, and have to wait the form being submitted, the server parsing it, and sending back an error 5 seconds later, you want the error to show instantly. You validate on the client, but you ignore the client validation entirely and validate again on the server.

If the validation is made client-side, the client may submit the request by hand, bypassing all validation. Even if you use hashing, signing, obfuscating or anything else, the result is an HTTP request and the client can intercept it and tamper it.

If your use case is what you asked, server validation it's not difficult at all. Have a table with all questions and all valid answers, and check every client answer with the table. On the first invalid answer you stop the processing and send back an empty page.

the number of possible permutations could make validation very difficult.

You have to choose between server-side (from trivial to very difficult) and client side (not possible at all). I believe the choice is easy.

Answer 2

You'll have to validate it on the server side. You say that the number of possible permutations is too large - but the client side somehow did it, didn't it? If the server side doesn't have enough information to efficiently validate the input, then have the client send more info. Worst case scenario - just send all the raw user inputs and re-calculate everything on server side, ignoring the client side work entirely.

Answer 3

The only way you can handle this is by authenticating the connection and controlling what happens in the browser. Authenticating the connection is of course possible, but to control the browser is another matter. You'd have to trust both the OS and the browser, and avoid leaking any authentication keys.

All in all: no this is not really possible, at least not for generic users. It may be possible to a certain extend if the computers are controlled by trusted entities. However, in general you should maintain a secure state on the server, and that includes validating input in case that can trigger such an invalid state.

Answer 4

Just a few notes:

Obfuscation isn't sufficient here.

Any client-side validation is essentially just as good as, and in a stretch of imagination can even be considered, obfuscation.

In a complex app, though, the number of possible permutations could make validation very difficult.

Validation is hard. I'd go so far as to say that validation can be one of the most difficult and persistent obstacles that web developers face. Too often do bad actors attempt to infiltrate any area of input. They're all attack vectors.

Unfortunately, systems which require complex validation often need custom solutions, but there are a few patterns and frameworks you can follow. For example, you can create infinitely customizable validators using ASP.Net. Here's a start if you're curious:

https://docs.microsoft.com/en-us/aspnet/core/mvc/models/validation?view=aspnetcore-6.0#model-state

Answer 5

A separate security device may work. Such a device should contain the private key that is impossible to get outside the device, own independent keyboard and a small CPU that can internally apply the internal private key for digitally signing the input. The signature then can be verified using external public key but the signed content cannot be forged. Something must also be done against replay attack (maybe include some single-use random sequence as part of the signed content).

In the simplest case the user can read the signed content on the single line screen of the device and type into the form of your website, so you do not need to program also drivers. The input could be intercepted and modified at this point, but then it will be wrongly signed.

Some banks use comparable devices for authentication in they websites. They must be robust against reverse engineering but they only need to discard the private key if being tampered.

Answer 6

Also, apart from the necessity of validation server-side to have any hope of security do NOT attempt to validate by any "economical" RegEx expressions.

Even if the legit user would only send you a certain class of strings, the bad people can send you "strings" with bad characters, which are too long, etc., so you do NOT want to give user inputs any leeway.

RegExp testing is subtle enough (DFA or not? greedy matching or not? ...) that it's not the way to go even if you have an idea about it. Make a look-up with hard-coded legit inputs.