Unless I missed something, I don't think anyone was suggesting that client side validation provides any security. I was just stating that, in general, decisions should be based on the bottom line, not a particular view - even if that view is right most of the time.
Regarding things you "should just do". I had a client that wanted an intranet app. He wanted the rock bottom lowest price. I explained all of the features he could leave out, including anything other than very basic server side validation (OK - I admit cfqueryparam is pretty much a must do). I fully explained all of the risks and strongly recommended certain measures but he made the choice to go lowball. I got it in writing but he paid the bills. His choice. Much of what I left out was in the must do column - at least in my opinion. All that said, I think we all agree here - this is all just nuance. Shane Heasley www.CTek-Media.com -----Original Message----- From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Jeremy Allen Sent: Monday, March 23, 2009 6:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) I always tell folks that client side validation is meant to save round trips to your server and improve your user experience. It has, in practice, a zero impact on the real security of your application. It will not defeat an attacker, even a script kiddie. We also advocate a risk based approach to security (e.g. don't spend $1,000,000 to protect a $10,000 asset). The real point here is that it is not a security feature and never will be a security feature as long as the user has control over the client, and that is not changing in a significant way for the foreseeable time to come in the web application market. I will step out on a limb here and state that only the smallest and tiniest concept type applications can afford to skip out on the data validation aspect of their application. Validating the incoming data and protecting against incoming injection attacks is not all that difficult if you do it properly from the start. In fact it probably makes your applications more stable by preventing situations where your input does not match with what the database can handle, etc. Things like input validation are not really on a sliding scale of user convenience and or cost like many security features. You can do it quickly and properly while enhancing the stability of your application. On the other hand things like password complexity there is a sliding scale of convenience where the more complex the passwords are the less likely users are to deal with it properly, if at all. So you must balance the convenience factor to your users while still maintaining an acceptable level of risk for the application. In some cases, say for a banking app, that level of acceptable risk is incredibly low. In something like a social networking app that risk is quite a bit higher. So there are some things that are debatable and other things you should just do :) Jeremy On Wed, Mar 11, 2009 at 2:40 PM, Shane <studio...@gmail.com> wrote: > This argument revolves around money - which is a point of view few > programmers ever take into consideration. What is best for the owner? > > Charlie is correct - the need for security varies. How does it vary? > Based on a risk / reward ratio that has to be chosen by the business > owner. Our job is to communicate to the business managers what the > risks are and what the costs are. Do you want to spend xx dollars to > mitigate this risk or would you prefer to take an approximately xx% > chance that this bad thing will happen in order to save $xx upfront > development costs. I tend to argue on the side of more security but > the final decision rests with the business owner. They pay the bills > either way. Usually, extra security is not very expensive but high security paradigms can be very expensive. > > Too many programmers think this is some kind of art. It isn't. It is > just producing a defined product in return for some perceived value. > > Lest anyone think I'm poking a finger at Dean - no. I learn something > new just about every post he makes. > > > > > -----Original Message----- > From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Charlie > Arehart > Sent: Wednesday, March 11, 2009 10:52 AM > To: discussion@acfug.org > Subject: RE: [ACFUG Discuss] over-stating security concerns? (was RE: > ValidateAt parameter is effectively only client side ) > > Sure, but I've got to ask: is that a concession to my point? :-) > > (that not every app that uses CFINPUT validation would be harmed if > some bastard removed it?) > > This isn't about me winning an argument, by the way. It's just that I > can't tell if you're letting it go because you think I can't be > convinced (or don't want to belabor the point), or because now that my > point is clear, you see it's not so loopy after all. :-) > > If you'd say it's the former, fair enough, and don't feel compelled to > make the point. I'm sure you've plenty busy, and others may feel that > the two sides have been represented. > > This was just another of my counters to the assertion that some > less-than-perfect features in CF need to be abandoned by all (CFFORM > being among those often named). I just say, that's just not so for > everyone. We just need to understand its limitations, and for that I > do thank you and others for keeping us in mind of that. > > /charlie > > > -----Original Message----- > From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Dean H. > Saxe > Sent: Wednesday, March 11, 2009 11:23 AM > To: discussion@acfug.org > Subject: Re: [ACFUG Discuss] over-stating security concerns? (was RE: > ValidateAt parameter is effectively only client side ) > > Of course there is no disrespect Charlie. I think we all need a big > group hug. ;-) > > > Dean H. Saxe, CISSP, CEH > > > > > ------------------------------------------------------------- > 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 > ------------------------------------------------------------- > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.237 / Virus Database: 270.11.9/1993 - Release Date: > 03/11/09 08:28:00 > > > > ------------------------------------------------------------- > 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=gin.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 ------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.24/2018 - Release Date: 03/23/09 06:52:00 ------------------------------------------------------------- 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 -------------------------------------------------------------
