Ah, ok. Now I see where you were coming from. Still, I have to argue against the assertion that any sort of client-side validation is "a completely useless waste of time". I mean, I get it. You make your living as a security consultant, and we're very lucky to have you here bringing such concerns to light.
And indeed many others here would want always to make that point and steer everyone clear of any client-side validation (or this pseudo-client-side validation in CF's very old hidden field approach, updated in CF7 to be enabled by the validateat=onserver.) But I wonder if sometimes it's an over-stated concern. To me, this is tantamount to someone asserting that everyone needs to have bars on their home's doors and windows, as well as an alarm system, video monitoring, and a gun at their bedside table. Do they, really? Sure, in some places. And it may also depend on what's/who's inside, or what experience the homeowner has had elsewhere, etc. But do we all (need to) do that? Of course not. In the same vein, some issues with CF are discussed as if everyone has the same concerns and requirements, that they're absolute. I don't know. For the average user, I'd propose that there's maybe not much real concern about whether someone even DID go so far as to circumvent any client-side (or this pseudo-client-side) validation. For most, I daresay the goal is just to make sure that their server-side code (or a database update) doesn't fail with an error, such as if they expect a number and someone put a character in the string. But really, for most apps, is it going to really hurt them if such errors occur? Yes, in some situations a failure to invoke protections could open the site to sql injection, or cross-site scripting, and so on. But I don't think that stuff is what most people use the CF validations for. It's just simpler stuff: is the input a number? A date? A zip code? Was it entered when required, and so on. Sure, there are also certainly some situations where errors that arise for lack of that validation (if circumvented) could go so far as to be used to cause a denial of service attack. Again, though, are we all really likely to experience that? (Do we all live in a rough neighborhood, going back to the analogy?) Are our sites so important that anyone would really care to bother? (Do we live near a school where people might pull a prank?) Would it be the end of the world if the site suffered a DOS attack and was unavailable for a period of time? Most would find and resolve the cause of the problem if it happened. Note that I've not said, "Do we really have anything on our sites worth their trying to break in to get?" I'm sure Dean and others would say, "ah, but there's where you're missing a point. It's not the value of what you have, but it's the value the hackers get in making your site now a launching pad for their dirty deeds." OK, sure. Again, I'm not speaking against protections like SQL injection, XSS, XSF, etc. I'm just talking about these simple validations. Still, one COULD assert that all protections should be enabled by all developers in all cases on all sites. But is it really necessary? This is all just going back to the assertions that CFINPUT (and CFFORM) are hopelessly useless tags because they don't do (or mistakenly do) something that someone would say is inappropriate. I'm just calling for reasonable consideration about whether those assertions really apply to everyone. I'm not saying Dean should stop being the canary in our coal mine. :-) He's awesome at that, and we're so blessed to have him here serving that role. And there's certainly nothing wrong with recommending other solutions (other approaches to validation). And indeed I realize Dean may have a very good retort to my contention here (again, it's what he's paid to do, and his company may well have had people make this very assertion in response to things they've proposed doing.) I just wanted to put this out there, for any who would bother to read it all, which I doubt will be many :-). At least until someone responds. Funny how we humans work. (Maybe I should have blogged this instead and pointed to it. I may still, but I'd welcome some back and forth first, in case I'm really making some egregious mistake.) /charlie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dean H. Saxe Sent: Tuesday, March 10, 2009 11:58 AM To: [email protected] Subject: Re: ValidateAt parameter is effectively only client side (was: "re[2]: [ACFUG Discuss] Password CFinput regular expression - throws alert/error after correction also") You are correct Charlie, it only puts the hidden field there to tell the server how to validate it. A completely useless waste of time, since those hidden fields are removed by anyone who wants to bypass your validation. In order to do this correctly it would implement the Apache Commons methodology of mapping a form name and formfield to a specific validation on the server when the data is received. This is done through reflection and cannot be influenced by the client. -dhs ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
