You and I are basically on the same page. I have always loved CFINPUT as a quick and easy way to implement client-side validation. You'd be hard pressed to find a (CF) application that I've written that does not contain CFINPUTs in just about every form. But I do it from the point of view of usability and reduction of load on the server for responding to invalid data. If I can save a round trip to the server with a line of code, I'd be silly not to. I've just never viewed using CFINPUT as security, nor validation.
As far as the runat server part of CFINPUT, I have never used it in a real application. I played with it maybe back on CF3 or 4, but thought the output was far uglier than I was willing to live with, and I thought it was clunky. So back then I'd write my own validation and responses. Now that I've got a framework for it, I don't even have to think about it really. All I do is configure it and walk away. Almost too easy. I also have code for stopping CSRF in its tracks, but that's another story for another time... ________________________________ From: Charlie Arehart <[email protected]> To: [email protected] Sent: Wednesday, March 11, 2009 10:48:41 AM Subject: RE: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) 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:[email protected] [mailto:[email protected]] On Behalf Of shawn gorrell Sent: Tuesday, March 10, 2009 4:39 PM To: [email protected] 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 FusionLink ------------------------------------------------------------- ------------------------------------------------------------- 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 -------------------------------------------------------------
