Why is client-side validation not enough?_问答_开发者

I saw here that:

As you probably already know, relying on client-side validation alone is a very bad idea. Always perfor开发者_开发百科m appropriate server-side validation as well.

Could you explain why server-side validation is a must?

Client-side validation - I assume you are talking about web pages here - relies on JavaScript.

JavaScript powered validation can be turned off in the user's browser, fail due to a scripting error, or be maliciously circumvented without much effort.

Also, the whole process of form submission can be faked.

Therefore, there is never a guarantee that what arrives server side, is clean and safe data.

There is a simple rule in writing server application: Never trust the user data.

You need to always assume that a malicious user accesses your server in a way you didn't intend (e.g. in this case via a manual query via curl instead of the intended web page). For example, if your web page tries to filter out SQL commands an attacker already has a good hint that it might be a good attack vector to pass input with SQL commands.

anyone who knows basic javascript can get around client side.

client side is just used to improve the user experience (no need to reload page to validate)

The client you're talking to may not be the client you think you're talking to, so it may be ignoring whatever validation you're asking it to do.

In the web context, it's not only possible that a user could have javascript disabled in their browser, but there's also the possibility that you may not be talking to a browser at all - you could be getting a form submission from a bot which is POSTing to your submission URL without ever having seen the form at all.

In the broader context, you could be dealing with a hacked client which is sending data that the real client never would (e.g., aim-bots for FPS games) or possibly even a completely custom client created by someone who reverse-engineered your wire protocol which knows nothing about any validation you're expecting it to perform.

Without being specific to Javascript and web clients and to address the issue more widely, the server should be responsible for maintaining its own data (in conjunction with underlying databases).

In a client-server environment the server should be ready for the fact that many different client implementations could be talking to it. Consider a trade-entry system. Clients could be GUIs (e.g. trade entry sysems) and (say) data upload clients (loading multiple trades from .csv files).

Client validation may be performed in many different ways, and not all correctly. Consequently the server shouldn't necessarily trust the client data and perform integrity checks and validation itself.

In case the attackers post their own form.

You can turn off/edit JavaScript.

Because the user agent (e.g. browser) might be a fake. It is very easy to create a custom application to create an HTTP request with arbitrary headers and content. It can even say it is a real browser—you have no way of telling the difference.

All you can do is look at the content of the request, and if you don't check it you don't know it is valid.

Server-side validation is a must because client-side validation does not ensure not-validated data will arrive in the server.

Client-side validation is not enough because its scope of action is very restrict. The validation is performed in the browser user-interface only.

A web server "listens" to and receives an HTTP request containing data from the browser, and then process it.

A malicious user can send malicious HTTP requests by many ways. A browser is not even required.

The client-side validation, performed using JavaScript, in the browser, is an important usability, user-interface enhancement. But it does not prevent malicious data to be sent by an user that knows how to circumvent the browser default behaviour of building the HTTP request that will be sent to the server. This can be done easily with some browser plugins, using cURL, etc.

In general, it's best for EVERY piece of an app to do it's own checking/verifications.

Client-side checks are good for maximizing the user-experience and speeding up the feedback to the client that they need to fix something, and to reduce the amount of problems encountered in the server-side checks.

Then at each major point of transition on the server-side code, you should have checks in place there too. Verify inputs within the application code, preferably via whitelist input validation, and then have any interactions with the database use parameterized queries to further ensure problems do not occur.

You should perform server-side validation on any data which, if invalid, could be harmful to anyone other than the entity posting the data. Client-side validation may be suitable in cases where invalid data would have no ill effects for anyone other than the entity posting it. Unless you can be certain that the ill effects from bad data will not spread beyond the entity posting it, you should use server-side validation to protect yourself against vandals or other rogue clients.

Client sided validation is for saving the client from entering wrong data. Server sided validation is for saving the server from processing wrong data. In the process, it also introduces some security into the submission process.

Client side validations presuppose a safe browser, a client side language, or HTML 5. All these elements could be disabled, partially unusable, or simply not implemented. Your website have to be used from every person, with every browser. The server side languages are safer, and -if they aren't bugs- the validation will be surely safer and right.

Buddy , Suppose if a person turnsoff the javascript in his browser , the validation became dead . Then if he post some malcious content through that form to the server side . It will lead to serious vulnerabilities like sql injection or xss or any other type of problems . So beware if you are going to implement a client side javascript validation .

Thank you