Data should be validated during submission

You can’t trust user data

User data is any data that’s provided by the user, either directly, or indirect. When a user provides an application data, that data should be sanitized. When processing user data, this can be nondeterministic and you should never assume the data provided is correctly formatted — or harmless. User provided data can somehow turn a finite algorithm into an infinite loop. I think it goes without saying, user provided data should be treated with caution.

This isn’t anything new in programming, and is especially important when a program with a higher privilege is accepting data from a user with lower privilege. For example, you accessing this website. Medium is accepting commands from you, which is running at a lower privilege — it must correctly interpret your commands.

Purpose of this Article

It pains me to see a lack of separation between trusted and non-trusted entities. I’ve seen a lot of applications developed that fall victim to this, because of a lack of sanitising. Developers need to treat user data as untrusted, and understand that a lack of securing the ring layers could lead to exploitation.

Validating Localized Data

One of the most difficult programming projects I’ve had to do is trusting privileged data on a untrusted system. Storing data on a system in which the user has the ability to execute or change Ring 0. Programmers that need to perform these actions have an extraordinary project ahead of them. For this post, I must assume this is not the case — your user can’t access Ring 0.

Runtime Validation

Validation of user data is very important, especially when data needs to be interpreted by an application with more privileges. Failure to do so could lead to denial of service, loss of sensitive data — deleted or exfiltrated, and more. Runtime validation can also control the flow of the application. For example, you may want to show different fields based on the data the user provided in previous fields or forms. However, this type of validation shouldn’t be trusted during submission, all data must be validated.

When a user is filling out a form, and validation is being done, this validation is only good for that time. You can provide the user feedback at this time as to the success or failure of validation. These results should not be stored for the purpose of submission, unless the user doesn’t have access to the data. This is because once validation is complete, the user can change the validated data.

Submission of Localized Data

Some time-saving practices involve saving data validation results and submitting the data once all validation is true. However, this can lead to incorrect data during submission as the user may alter data before being sent, intercept data to alter it, or replaying with modified data. In some cases, validation can be bypassed all together by collecting the format in which data is sent, alter it, and send erroneous data. Allowing a user to do this can lead to exploitation, and access to higher privileges.

Example

When the Xbox app first came to Windows, it allowed you to take screenshots of games you were playing. Once you exited your game, you could then upload those screenshots. The Xbox app would validate the image taken before uploading. If you changed the image to something else, it would not allow you to upload the image. However, if you started the upload process, once validated, it would allow you to post a message too. Once validation is complete, you could swap out the image with what ever you wanted. An application like this is very difficult to protect, as intercepting the communication could also be done. This is just a small example of the difficulty of validating data.

Conclusion

When a user submits data, final validation needs to be done on submission. This can be done when the user doesn’t have access to the same privileges as the application, or higher. This is because validated data could be altered if the user has access, for example localStorage or cookies in the browser.