views:

54

answers:

4

I don't quite understand why client side validation is a potential security risk or more of a security risk than server side validation? Can someone give me some scenarios?

+1  A: 

If you do validation only in client-side, someone may disable javascript (or change the js code, with firebug, for example). So, all validations made in js would be useless and user can insert invalid data in your system.

Topera
+1  A: 

I assume you're talking about a web scenario?

If you're doing client side validation with Javascript, what happens if the user has Javascript disabled? Then they can submit data to the server that has not been validated.

If they were sneaky, they could even post data directly to your server (bypassing your page completely).

If you do server side validation, in addition to or instead of client side validation, then you have an additional opportunity to defend against these scenarios.

Jason
+4  A: 

Using various tools, such as Fiddler, Noscript, Web Developer, etc., I could disable the client-side javascript validation, and modify the data being sent to your server. Depending on the type of data and what the server does with it, one could initiate a SQL injection attack, attempt to compromise the server security, or simply store bogus data.

A lightweight example: Say you have client-side validation to ensure that a zip code is 5 digits or 5+4 digits. If I disable the client-side script, I could leave my 24-digit value in place. If your server doesn't further check the value, and the database is capable of storing all 24 digits, then I have saved the bogus data.

JYelton
Thanks for telling me about these tools.
Xaisoft
+5  A: 

Ideally you'd do both client and server side and never one or the other. If we take at look at these 3 scenarios, both is the only secure, user-friendly way to do it:

Client Side Only: As mentioned, it doesn't take much to get around these validations if somebody wants to send malformed data to your server (such as SQL injection). NoScript won't run the javascript validation code, and some browsers allow the user to actively change all loaded javascript and html, so a user could unhook the validation javascript from the controls.

Server Side Only: This one is more secure than Client-only by a long shot, but cuts back on user friendliness. They have to send their form to the server, have it validated and receive the error page back saying a particular field was invalid. What's annoying is that if any of those fields were password fields, their values are not repopulated by default. For example, lets say the user didn't input a phone number correctly in an account creation form. When the server spits back the page about how the phone number is wrong, the user will see that, correct the phone number and hit submit again, just to receive another error page about not having entered a password (and entering it again in it's second textbox) even though that wasn't the initial problem.

Client and Server Side: You get the security of the server side validation, something the user will be hard-pressed to interfere with, and the user friendliness of input validation without having to submit the page (whether you validate through purely local javascript or AJAX).

If you absolutely had to pick one, server side would be the way to go. But you shouldn't ever have to pick one or the other.

Corey Ogburn
Thanks for the explanation, it makes much more sense now.
Xaisoft
It was a question I had back in school when I started learning server side technologies. It's all about the big picture of things.
Corey Ogburn