How to prevent attacks against client side validations?

Question

I have a login form where am accepting Mobile Number of the User for login.

When Mobile Number is submitted, am calling a JavaScript to validate the Mobile Number. My client side validations consists of checks like does Mobile Number starts with 9, 8 or 7 , is the length of Mobile Number equals 10 etc.

Once these kind of validations are done, am checking at Server side if entered Mobile Number and password matches(Authentication).

Since I have some checks in JavaScript, one can view the source and come to know that these kind of checks are there. And one can modify this code and let that to reflect for all Users. For eg., one can change the code which does the check if Mobile Number starts with 9, 8 or 7 and replace 9 with 1(say). So, if one enters Number starting with 9 it will fail.

1. How to prevent these kind of attacks? Obvious way is to put these checks at server side, but I have atleast 10 different checks and I don't want to overload server side checks.

2. How can attacker change those values in my JavaScript and let that to reflect for all Users?

EDIT : My client side JavaScript code looks like below,

var checkMobileNumber = form.mobileNumber.value;
if (checkMobileNumber.charAt(0) != 9 && checkMobileNumber.charAt(0) != 8 && checkMobileNumber.charAt(0) != 7) {
  //Throw some error
}

Answer 1

To do 10 checks on the server side is likely not going to put any real stress on your server. Unless you are at the point of thousands of request per second, you will be okay. At that point, you would probably implement clustering, etc. Security is always worth the extra cycles. Client side validation is never sufficient. When you think about validation, you should think about filtering RAW HTTP without regard for the fact that the "browser" may have generated the content.

Even if there is client side validation, there are still Man-in-the-middle attacks, where they can change the content of the raw HTTP request after the validation has occurred. Client side validation is really for end user convenience so they don't submit, then get an error message and have to resubmit. I would not consider client side validation in a browser based application to provide any security for processing being done on the server.

As for how an attack can modify your validation, it would depend on many things. For example, what are the dynamic values on the page - do you take parameters from the query strings (GET parameters) without filtering? This could lead to XSS or CSRF attacks because they can change those values and your application will process them. Of course you can protect against this with proper escaping and other techniques. The attack may also have loaded some type of user script or proxy which can inject code into the page.

Since you are using "reflected", you may want to read more specifically about a "reflected XSS", which is just one type of attack vector. From OWASP:

Reflected attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a "trusted" server.

Answer 2

you already know what to do,,,the problem is you have more things to validate. Simple answer is if you want secure things, do all the validations in server side. What ever you've done for client side things, hackers can see them and can change.

(do not forget about mitm attacks. client side validation not gonna help)

Answer 3

You have ZERO control over what a user submits to the server. A fundamental security concept is never trust the user, and this applies in cases such as these. Use your client side protections to prevent accidental malformed requests (person mistypes) and for convenience reasons. Trying to harden these checks to become 'secure' is fundamentally flawed.

Ensure all your security validations are done server side, regardless of how much load it in turn puts on your server, unfortunately you don't have any other choice.

Answer 4

Well, if you don't want to put load on the server, your “security” is broken. You may put whatever security you want on the client side, a savvy client will always be able to send what s/he likes to your server. Your server must not trust client input. You must not suppose that the stuff your server receives comes from the software you have put at the client side. This may be the nominal case and the only case you have imagined, but a savvy user can send whatever content s/he wants to your server. S/he can alter your client side software, s/he can bypass it…

The server load is not a worry — otherwise you really have to buy better hardware. And the server load can be minimized.

Nice Web app frameworks — like Vaadin — allow you to develop the validation once and to have it run at both places, on the client and on the server. So you have these advantages :

• The server-side validation is the secure validation.
• The client-side validation is the reactive validation, the user does not have to wait for a server round trip to have the validation feedback.
• Most of the time, the server receives valid user input, because most users have first passed the client-side validation. No client / server round trips for the usual user errors. So the server load is minimized, network load is minimized, this is good for energy saving, this is good for your electricity bill, this is good for the planet.

And you can save more by doing less. Are all your constraints on the phone number really good ideas ? What will happen if one user has a phone number from some country you did not think of ? Do you know that people can take their mobile phone across borders ? What will happen if one user writes his phone number with spaces ? These cases will give bad user experience. Are there really good reasons to forbid these cases ? Or will your constraints just be nuisances that will do more harm than good ?