You make some good points, Shawn, but I'll say you also make a couple that seem to back up part of my point.
First, you conclude, that "some of live in environments where we can't afford to get embarrassed by an outside security group." Well, I certainly don't disagree with that at all. It was the main point I was making: yes, some do have to undertake all care in all apps. I just don't think all of us do. You also said, "That doesn't mean I don't use CFINPUT or other client validation, because I always do, but not for the sake of security." Well, again, that was my point. I was only discussing the arguments people make against it from a security standpoint. I don't see most CFINPUT features as security feature, but as you say a convenience (easy for the user, helps prevent errors on the server.) I just think, for some, that's better than nothing at all. Still, I don't at all disagree that for security reasons one could and should do server-side validation. I really wasn't arguing against server-side validation. I didn't state it, but I will not. Still, I'll argue that for most it should only go so far as protection against reasonable intrusions (and to a degree suited to the app and the risk), as opposed to implementing some lock-tight approach that takes a lot of work. But certainly if one could have an easy-to-implement, configuration-based validation process that enables both client- and servers-side validation in one fell swoop, and that would satisfy the concerns of those knowldegeable in security matters, then sure, it would be a good thing to do. /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of shawn gorrell Sent: Tuesday, March 10, 2009 4:39 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) Dean won't be the only one to disagree. I don't see client side validation as validation at all. It is merely a convenience to end users and offers no protection IMO. That doesn't mean I don't use CFINPUT or other client validation, because I always do, but not for the sake of security. As far as the "small and low risk app argument", I would say that practicing defense in depth adds very little time to the development process to add (real) validation at the server and database layers, so why skip it. If you use a validation framework, such as what John just presented on, or what I've got in Tardis, it isn't even coding to validate. It is configuration. Very easy to maintain. An additional consideration that we deal with where I work is that there is really no such thing as an app that it's ok to have a vulnerability in. If we have a small thing that gets burned on a PEN-test, it is just as bad as it being a big, high risk thing. Is that silly? Yeah, it is. But some of live in environments where we can't afford to get embarrassed by an outside security group. S ------------------------------------------------------------- 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 -------------------------------------------------------------
