in reply to Do I have to untaint all user input in a form?

I do most of the heavy lifting in...(gulp)... Javascript

If the client has JavaScript shut off, what do you do? JS validation should only be used to save a server request that would be rejected anyway. It doesn't end your responsibility of having to do validation server-side.

do I have to validate every user input value

Taint mode won't force you to do so, but it's a good idea.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Do I have to untaint all user input in a form?
by bradcathey (Prior) on Nov 14, 2003 at 16:04 UTC
    Thanks hardburn for that reminder.

    The reason I "gulped" originally, was because I know the bias around the monastery against JS. And I'm starting to agree with a lot of it, including your comment:
    JS validation should only be used to save a server request that would be rejected anyway.
    Which is precisely the way I intend to use it (now that I catching the security mojo here at PMs). Until I started coming to the monastery, I never met anyone who turned off javascript. And for those who don't, which is probably the average surfer—good or bad, client-side validation can very quickly check values, and limit the server side checks, which take more time and have to refresh screens, etc.

    What I'm attempting to do is provide a fast pre-validation for those who want it (or haven't disabled JS), and then the more critical, security conscience validation on the server side.

    All that to say, your point is well-taken.

    —Brad
    "A little yeast leavens the whole dough."
[reply]
      The only problem i have with JS validation is that it is going to produce redundant code. You see that JS validation is no substitute for server-side validation, as tools such as LWP and crew make it very easy to bypass your front-end "security". As long as you don't mind maintaining both the JS and server validation, then god-speed to you, but i still think that JS validation is waste of my time and my client's money. ;)

      UPDATE:
      I can admit that what sauoq says is good - if you do have some expensive submission that will benefit from being validated on the client side first, well ... go for it. Some redundancy isn't so bad, especially when you compare the chore of keeping it consistant to ... washing dishes. :D It just ain't so bad after all. ;)

      jeffa

      L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]

        There is at least one good side to JS validation: zero latency between submission and feedback that there was an error.

        It's like one of those little icing flowers on a cake: it doesn't change the nutritional value and it should always be added last.

        -sauoq
"My two cents aren't worth a dime.";
[reply]
        ...but i still think that JS validation is waste of my time and my client's money.

        I haven't used it, but CGI::FormBuilder looks like an easy way to automatically generate (in JavaScript) at least some of the client side validation and then do the server side validation (at least for the supported types of fields). It is supposed to easily plug into HTML::Template and Template-Toolkit.

[reply]
        Wow, one question/one day and I'm becoming a BELIEVER! Between jeffa and hardburn I'm starting to see da light. Double the code, double the hassle, and all for what? I guess it comes down to..."Let 'em wait half a second!" I didn't realize monks could be so evangelical. But why is that a surprise with slogans like "use strict or die." I'll have to work on a Javascript T-shirt. Thanks.

        —Brad
        "A little yeast leavens the whole dough."
[reply]

In Section Seekers of Perl Wisdom