The question of whether input validation should be performed on the client side or server side is one that has been debated time and time again. There are pros and cons to both approaches, and ultimately the decision of which one to use depends on the specific situation. As web applications are developed, the input received from the client is often stored or reflected back to the user. Then, as security implications were discovered, it was understood that the input needed to be validated. Developers were then advised to restrict or sanitize the user's input.
While some developers only validate on the client-side (e.g., JavaScript), some validate on only the server-side, while others validate on both. Below, each type will be broken down to understand its importance.
Input Validation on Client-Side
Client-side validation is visible to the user. It involves having validation on input forms through JavaScript. For example, if the input is submitted for a phone number or email, a JavaScript validator would provide an error if anything is submitted that does not conform to a phone number or email. For example, below we will see how client-side restrictions could be easily changed.
The following form will only submit if the phrase “success” is submitted.
Figure 1: Client-side Input Validation, Stage 1
However, a token error is presented when “success” is submitted.
Figure 2: Client-side Input Validation, Stage 2
This means that the request is submitting a token in addition to the phrase. In order to see what is being done, we can take a look at the request using an interception proxy (such as Burp Proxy).
Figure 3: Client-side Input Validation, Stage 3
Now that we have confirmed our suspicions, we need to understand what is being used to generate the token. Given the JavaScript is provided to us to populate the page, we can easily view the code.
function rot13(inp) {return inp.replace(/[a-zA-Z]/g,function(c){return String.fromCharCode((c<="Z"?90:122)>=(c=c.charCodeAt(0)+13)?c:c-26);});}function generate_token() {var phrase = document.getElementById("phrase").value;document.getElementById("token").value = md5(rot13(phrase));}generate_token();
The code above will take the phrase from the input box, run it through a simple substitution cipher (rot13) and then md5 it. We can confirm this by taking the phrase “ChangeMe” and running it through a rot13 substitution which would present us with “PunatrZr”. The hash of “PunatrZr” is 8b479aefbd90795395b3e7089ae0dc09, which matches the token in the request above.
If the phrase “success” is to be successfully submitted, we will need to do the same steps as we did for “ChangeMe”.
The rot13 of “success” becomes “fhpprff”
The md5 of “fhpprff” is 38581812b435834ebf84ebcc2c6424d6
The next step would be to intercept the request before it is sent to the server and modify the token to be that of 38581812b435834ebf84ebcc2c6424d6.
Figure 4: Client-side Input Validation, Stage 4
Once submitted, we’ll receive confirmation that it succeeded.
Figure 5: Client-side Input Validation, Stage 5 – Bypassed
JavaScript has to be accessible by the browser (and therefore the user) to ensure the web application functions as it should. As seen above, any restrictions can be quickly reverse engineered or even bypassed entirely.
Input Validation on Server-Side
Server-side input validation will take whatever is sent by the client and conduct additional checks. Using server-side validation indicates that any input sent by the user (or client) cannot be trusted.
In order to show how effective this is, the following form is vulnerable to Cross-Site Scripting.
Figure 6: Server-side Input Validation, Stage 1
If a JavaScript payload is submitted, the alert box will appear.
Figure 7: Server-side Input Validation, Stage 2
This implies that the request was sent to the server and reflected back to the client without any validation. In these examples, we have access to the underlying source code to validate our claim.
echo ‘<pre>Hello ‘ . $_GET[ ‘name’ ] . ‘</pre’;
There are many approaches that can be taken to validate from the server-side, and one can simply be to remove JavaScript tags when the name is sent back to the client.
The same payload was sent but now the alert box was not populated.
Figure 8: Server-side Input Validation, Stage 3 – Fail
Taking a look at the source, we notice that any presence of a script tag within the name variable will be replaced.
$name = str_replace( ‘<script>’, ”, $_GET[ ‘name’ ] );
These simple replacements can be by-passed using other Cross-Site Scripting payloads. The recommended solution is to use the PHP htmlspecialchars() function that will encode user input to completely prevent Cross-Site Scripting.
$name = htmlspecialchars( $_GET[ ‘name’ ] );
Which Input Validation Should You Use?
In general, it is best to perform input validation on both the client side and server side. Client-side input validation can help reduce server load and can prevent malicious users from submitting invalid data. However, client-side input validation is not a substitute for server-side input validation. Server-side input validation is essential to ensure that only valid data is processed by the application.
While running a dynamic application security test, tools used will bypass the client-side restrictions to attempt injection attacks (e.g., Cross-Site Scripting, SQL injection). Each piece of input must be validated on both ends to ensure injection attacks are mitigated.
Doing input validation on both the client side and server side has a number of benefits:
It helps reduce server load since invalid data is never submitted in the first place.
It helps prevent malicious users from submitting invalid data.
It can help improve application performance since the application doesn't have to waste time processing invalid data.
Ultimately, the decision of whether to perform input validation on the client side or server side depends on the specific situation.
