6

I recently created a .net web app that used over 200 custom validators on one page. I wrote code for both ClientValidationFunction and OnServerValidate which results in a ton of repetitive code.

My sql statements are parameterized, I have functions that pull data from input fields and validates them before passing to the sql statements or stored procedures. And the javascript validates the fields before the page submits. So essentially the data is clean and valid before it even hits the OnServerValidate and clean after it anyways due to the aforementioned steps.

This makes me question, is OnServerValidate really needed when I validate on the clientside?

Edit:

My OnServerValidates do simple things like making sure a skip pattern is enforced or that a short appears in a text (which is enforced anyways with my code that pulls data from text fields into parameters i.e. GetShort()). And these are being place in patient surveys, which most of the time are filled out by staff members.

So it seems like if I didn't have the OnServerValidate for these basic checks and just client side the following situations are:

  1. A user turns off javascript and cannot submit the form, which is expected as buttons are javascript driven for postbacks.
  2. A user forces a post. Which if this occurs my OnServerValidate would do jack to stop whatever they are trying to do since it is just looking at skip patterns, or would it?

Situation 2 is where I am getting lost. It seems like the user forcing a post is more than likely not to be caught by these simple OnServerValidates

peroija
  • 163
  • 6
  • 3
    It is trivial to construct a post request that doesn't even need to pass through your client side scripts – HorusKol Oct 22 '12 at 21:13
  • To see just how trivial it is to completely bypass client side scripts and even the browser entirely, see [this answer](https://softwareengineering.stackexchange.com/a/364630/121035) on a closely related question. – 8bittree Sep 19 '19 at 17:39

2 Answers2

16

You do need them as the client can decide to allow javascript in their browsers. You also should consider those people who want to break your software. There are plenty of tools out there that can manufacture posts and submit them to your website without having used your front end.

Client side validation is nice for the user, but the server should never ever trust data that is sent to it.

--Update--

If I'm reading your edit properly, it sounds like the OnServerValidates are duplicating validation functionality that is already present on the server. Since that's the case, then you shouldn't need the OnServerValidates.

Furthermore, you are correct that if a user manufactures a post to your service, it will not trigger the OnServerValidates so you are better off keeping that type of validation where you have it currently on the server.

Brian Dishaw
  • 859
  • 10
  • 15
  • but if they turn off javascript, they can't submit the page because the .net buttons are javascript driven. And even if they manufacture a post I still have code that validates input data before it even goes to the database. If its not valid, nothing goes to the database. So the `OnServerValidate` seems to be an unnecessary 3rd step. Am I missing something else? – peroija Oct 22 '12 at 12:35
  • "I still have code that validates input data before it even goes to the database". I'm surprised you aren't doing this validation (Business Logic) in the OnServerValidate(s). By using the validation controls you get nice ways to handle error messages back to the client after a postback. Why do the extra work and validate outside of that pipeline? – Brian Dishaw Oct 22 '12 at 12:59
  • As for the javascript driven buttons, they still have a HTTP site that is receiving the request. This means anybody can post arbitrary data to your website. – Brian Dishaw Oct 22 '12 at 13:00
  • 6
    @peroija Its not that they can turn off javascript. Its that they can still send the complete data packet for the submission without using your page. Client side validation is good to protect the user from a silly mistake. Server side validation protects you from someone wishing to violate you. – Rig Oct 22 '12 at 14:09
  • I get that something can be forced and client side can't stop that. But if queries are parameterized please explain to me the issue. If you force garbage to me and I'm expecting a number from a radiobuttonlist the parameter will say no I need a number and throw an exception and the person receives an error page that says sorry, please try again. I'm not trying to be naive I am just not understanding the problem giving the other checks I mentioned that I'm using. – peroija Oct 22 '12 at 14:20
  • 4
    Parameterized queries will only prevent Sql Injection. There are a host of other way users can insert malicious data into your system and affect your users. Here is a link that talks about a five common ones. http://www.symantec.com/connect/articles/five-common-web-application-vulnerabilities – Brian Dishaw Oct 22 '12 at 15:15
  • 1
    +1 for "the server should never ever trust data that is sent to it" – David Peterman Oct 22 '12 at 20:37
  • so things seem to have gone in a different direction than I had intended, which is more than welcomed as I learned more. Please see my edit as I should have included more of these details in the original post. Thanks for all the discussion as this is helping me greatly and more than likely others as well. – peroija Oct 23 '12 at 12:00
3

If I was going to skip doing validation, I'd be much more likely to do it on the client than on the server.

The problem with skipping it anywhere is that someone may open up a security hole by assuming validation is being done when it's not.

Satanicpuppy
  • 6,210
  • 24
  • 28