I saw here that:
As you probably already know, relying on client-side validation alone is a very bad idea. Always perform appropriate server-side validation as well.
Could you explain why server-side validation is a must ?
views:
398answers:
13
+22
A:
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.
Pekka
2010-08-14 13:34:23
It applies to everything having a client, for example online games, and so, as said by @Pascal, you can't trust the client. And, in the case of webpages, they are the easiest to fake =/
grilix
2010-08-14 19:01:20
+7
A:
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)
Paul Creasey
2010-08-14 13:35:53
+4
A:
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.
Brian Agnew
2010-08-14 13:52:21
+3
A:
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.
Dave Sherohman
2010-08-14 14:06:06
+5
A:
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 a good hint that it might be a good attack vector to pass input with SQL commands.
DarkDust
2010-08-14 14:09:20
A:
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.
supercat
2010-08-14 14:34:14
You need to validate it even if it would only harm the submitter, due to the possibility of cross-site request forgery attacks. http://en.wikipedia.org/wiki/Cross-site_request_forgery
Dave Sherohman
2010-08-14 15:07:32
@Dave Sherohman: Thanks for the correction, though I'm not sure I understand it. If a rogue user agent submits bogus information which has no effect other than to return bogus data to the rogue user agent, how will that enable the attack? Who is assumed to trust who, and what mischief will be allowed to happen that the rogue user agent couldn't do itself?
supercat
2010-08-14 20:30:06
Imagine a rouge agent constructs an invalid query, and entices the target to execute that query, perhaps through a hidden iframe The bogus response will be from your domain, with access to your applications cookies, for example. If the bogus responce allowed the injection of client side code, the attacker could steal the cookies and subsequently launch further attacks with this new information.
Douglas
2010-08-15 00:05:38
@Douglas: I'm unclear who plays what roles in your example. Are you suggesting the response to the query will go to someone other than the rogue agent that sent it? If so, that would violate the "have no ill effects on anyone other than the entity posting it" condition. Basically, I was thinking of situations where a bogus input might cause some code to output data which was meaningless. For example, an anagram solver might client-side restrict the input to letters and blanks, but on server-side might simply fail to find anagrams for inputs containing other characters.
supercat
2010-08-15 15:17:56
@supercat: Sorry, the example wasn't particularly clear (it brings up issues which should be handled by proper output escaping, rather than input validation). The point I'm trying to get at is that the person who constructed the malicious query might not be the person who executes the malicious query, so you still have to play safe. A recent example of someone messing about along these lines: http://giorgiosironi.blogspot.com/2010/08/google-never-removed-oracle-from-its.html The attacker sought to make negative press for Google by distributing a malicious query for others to execute.
Douglas
2010-08-15 16:59:40
A:
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.
J. Bruni
2010-08-14 14:57:13
A:
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.
r3st0r3
2010-08-14 16:52:58
A:
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.
JGB146
2010-08-14 17:28:32
A:
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.
Charlie
2010-08-14 23:51:03