As web applications are developed, the input received from the client is often stored or reflected back to the user. As security implications were discovered, it was understood that the input needed to be validated. Developers were then advised to restrict or sanitize the users 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 validation on input forms through JavaScript. For example, if 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.

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 by-passed entirely.

Input Validation on Server-side

Server-side input validation will take whatever is sent by the client and conduct addition 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 of 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.

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.

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.

Which input validation should you use?

Both. By validating on the client-side, you have a smoother user experience and by validating on the server-side you ensure any client-side restrictions that were by-passed are validated again before being stored or reflected back to the user. While running a dynamic application security test, tools used will by-pass 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.

If you require assistance with testing your web application server for injection attacks, contact us for a quick quote.