That's how I feel about the whole "scriptprotect" thing. I think it is actually worse to put something in which creates a false sense of security than do to nothing at all.
________________________________ From: Dean H. Saxe <[email protected]> To: [email protected] Sent: Tuesday, March 10, 2009 4:56:19 PM Subject: Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) FWIW, I think Adobe and the CF team are doing a disservice to the community by supporting a known broken solution. Its time to get with the program and figure out a better way. I know Adobe has a strong security group, I'm just confused as to why they'd let something so obvious slide. -dhs Dean H. Saxe, CISSP, CEH [email protected] "[T]he people can always be brought to the bidding of the leaders. This is easy. All you have to do is to tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country." --Hermann Goering, Hitler's Reich-Marshall at the Nuremberg Trials On Mar 10, 2009, at 4:54 PM, Dean H. Saxe wrote: > Charlie, > > I never said its a waste of time. I probably said, its a waste of time if > there is no valid server side code to back it up. And by that I mean server > side code that cannot be manipulated by the client such as you have with > CFInput. > > Here's the reality: The average coder writes some seriously craptacular > code. From a security perspective, its even worse. Should every developer > be a security guru? No. Should every developer know and follow some best > practices? Absolutely. Whether its security or general design, every > developer should be aware of industry best practices and attempt to follow > them. They won't get it right every time, but if the do get it right 90% of > the time we're a long way toward solving some of the problems that plague us. > > When writing it correctly takes marginally longer than writing it incorrectly > AND over the course of a project's lifetime saves time/money by doing it > correctly the first time, is there any reason NOT to do it correctly? To put > it another way, if a developer told you he didn't want to bother to learn a > framework because it would cost him a week's time today, would you trust that > he has sound judgement to think about the full lifecycle of a project? I can > save a week today! (But it cost me many times that in the future because we > had a mess of spaghetti code...) I think the argument is the same. > > Finally, many attacks are fully automated and looking for easy targets. This > just makes an easy target which, in turn, serves as a launching point for > other attacks. > > I respect your opinion Charlie... even when you're wrong. ;-) > > -dhs > > > Dean H. Saxe, CISSP, CEH > [email protected] > "Free speech exercised both individually and through a free press, is a > necessity in any country where people are themselves free." > -- Theodore Roosevelt, 1918 > > > On Mar 10, 2009, at 4:27 PM, Charlie Arehart wrote: > >> 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 >> ------------------------------------------------------------- >> >> >> > > > > ------------------------------------------------------------- > 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 > ------------------------------------------------------------- > > > ------------------------------------------------------------- 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 ------------------------------------------------------------- ------------------------------------------------------------- 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 -------------------------------------------------------------
