1

While perusing ASVS 3.0.1 I came across requirement V5.18:

Verify that client side validation is used as a second line of defense, in addition to server side validation.

Umm... is client-side validation not said to have no security benefit whatsoever?

I mean, as a convenience function to alert users to undesired input, yes, but as a security requirement? Have I missed something?

countermode
  • 684
  • 1
  • 7
  • 22
  • 2
    What it means is: "If you find client-side validation, check there is matching servers-side validation." It does NOT mean "you must have client-side validation" – paj28 Sep 06 '16 at 12:41

2 Answers2

3

All right then, answers to my question on the ASVS mailing list shed some light on the issue. Personally I find the following two to be the strongest arguments:

  1. While client-side validation can be bypassed, it helps to detect attacks. Suppose for instance that there is an input field that length limited to 10 digits. If this is supposed to be client-side validated and the application receives something longer or a string containing non-digits, then it is (in a fuzzy sense) clear that something is going on.

  2. Applications with a lot of JavaScript that modifies the DOM where the server actually never sees some of the input require this. I realized only then that ASVS lacks a dedicated section on client-side testing (as the Testing Guide has).

countermode
  • 684
  • 1
  • 7
  • 22
0

Yes, client-side validation can be trivially bypassed. Still, it is adding some security and minimising the total risk, even if by a very small amount.

Being able to alert(1) directly from my browser, as opposed to using a proxy/extension IS an advantage for the attacker.

Here is an example: think of a hardened locked-down internal thin client, where the only thing you can use is a browser (you cant disable javascript). If there is no client side validation, I can exploit that SQLi that resides in the production DB manually.

Iraklis
  • 651
  • 4
  • 7