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 From: Charlie Arehart To: discussion@acfug.org Sent: Tuesday, March 10, 2009 4:27:50 PM Subject: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) 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 wron
Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
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 d...@fullfrontalnerdity.com "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 t
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 d...@fullfrontalnerdity.com "[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 d...@fullfrontalnerdity.com "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 ana
Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
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 To: discussion@acfug.org 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 d...@fullfrontalnerdity.com "[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 > d...@fullfrontalnerdity.com > "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) valid
Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
One more reply to myself... On Mar 10, 2009, at 4:54 PM, Dean H. Saxe wrote: Here's the reality: The average coder writes some seriously craptacular code. From a security perspective, its even worse. I too have written some seriously bad code in my life. Like anything, coding takes practice. Years of practice. There are a few gurus, a few bad apples and a lot of people in the middle, a typical bell curve. I'd consider myself part of that middle group who is lucky to know and be able to bend the ears of a few people on the guru side of the curve on occasion. There are many topics I am passionate about and know quite well. But there are many, many more where I am clueless and need to learn from others. -dhs Dean H. Saxe, CISSP, CEH d...@fullfrontalnerdity.com "Free speech exercised both individually and through a free press, is a necessity in any country where people are themselves free." -- Theodore Roosevelt, 1918 - 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 -
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: 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 -
RE: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
Well, you did specifically call it a "completely useless waste of time": :-) > 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. I realize you were referring primarily to the server-side validation that CF implements by use of hidden fields. And I get that you find it unacceptable because it's easily removed. My point, though, was that for many apps, even if that validation was removed, it wouldn't **open any security hole**. Could Adobe do something more? Sure. Should they, to protect those for whom that risk opens a hole? Sure. But does it really open a hole for everyone who uses it? I really don't think so. So I'm just saying it's not "a completely useless waste of time". To extend your argument, if someone creates a form and doesn't think to do any validation, I'd question THAT wisdom. If they use CFINPUT and implement client and/or server-side validation, since it takes just a single attribute, I'd say "better than nothing". Could they go still further? Sure. And until Adobe does make it easier, I agree with you guys that for many it would be worth it to find and implement another framework. But I think there are just as many for whom, given what their forms (and apps) do, it just may not be that critical. All that said, I'm also not a fan of this server-side validation as Adobe has implemented it because it relies on presenting an error page, and the user must back up. In some browsers/situations, that can cause loss of the input. Again, I'm not saying that the CFINPUT server-side validation is perfect. Far from it. I'm just saying it's not really a "complete waste of time", at least not from this concern of it being removable. My point is that for many apps, even if it's removed, it doesn't open any security hole. It just causes errors that might otherwise have been avoided. Isn't that better than doing nothing (even if it's not as good as doing much more)? :-) Thanks for your kind regards, Dean, and you know this is all done in a spirit of collegial debate. No disrespect intended at all. /charlie -Original Message- From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Dean H. Saxe Sent: Tuesday, March 10, 2009 4:54 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) 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 d...@fullfrontalnerdity.com "Free speech exercised both individually and through a free press, is a necessity in any country where people are themselves free." -- Theodore Roosevelt, 1918 - 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 -
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 d...@fullfrontalnerdity.com "Great spirits have often encountered violent opposition from weak minds." --Einstein On Mar 11, 2009, at 11:05 AM, Charlie Arehart wrote: Well, you did specifically call it a "completely useless waste of time": :-) 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. I realize you were referring primarily to the server-side validation that CF implements by use of hidden fields. And I get that you find it unacceptable because it's easily removed. My point, though, was that for many apps, even if that validation was removed, it wouldn't **open any security hole**. Could Adobe do something more? Sure. Should they, to protect those for whom that risk opens a hole? Sure. But does it really open a hole for everyone who uses it? I really don't think so. So I'm just saying it's not "a completely useless waste of time". To extend your argument, if someone creates a form and doesn't think to do any validation, I'd question THAT wisdom. If they use CFINPUT and implement client and/or server-side validation, since it takes just a single attribute, I'd say "better than nothing". Could they go still further? Sure. And until Adobe does make it easier, I agree with you guys that for many it would be worth it to find and implement another framework. But I think there are just as many for whom, given what their forms (and apps) do, it just may not be that critical. All that said, I'm also not a fan of this server-side validation as Adobe has implemented it because it relies on presenting an error page, and the user must back up. In some browsers/situations, that can cause loss of the input. Again, I'm not saying that the CFINPUT server-side validation is perfect. Far from it. I'm just saying it's not really a "complete waste of time", at least not from this concern of it being removable. My point is that for many apps, even if it's removed, it doesn't open any security hole. It just causes errors that might otherwise have been avoided. Isn't that better than doing nothing (even if it's not as good as doing much more)? :-) Thanks for your kind regards, Dean, and you know this is all done in a spirit of collegial debate. No disrespect intended at all. /charlie -Original Message- From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Dean H. Saxe Sent: Tuesday, March 10, 2009 4:54 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) 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 d...@fullfrontalnerdity.com "Free speech exercised both individually and through a free press, is a necessity in any country where people are themselves free." -- Theodore Roosevelt, 1918 - To unsubscribe from this list, manage your profile @ htt
RE: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
Sure, I agree with that. And I'll say I did clarify that protecting against SQLI, XSS, XSF, and the like is a very different subject, and even if one has no valuable assets in their site, they're worth protecting against because that site could be defaced, used to launch attacks against others, etc. I really was just saying that I don't think all situations where one might remove CF's hidden field approach would necessarily open a security hole. /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of shawn gorrell Sent: Tuesday, March 10, 2009 4:59 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) 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 To: discussion@acfug.org 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 - 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 -
RE: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
If it wasn't obvious, I meant to say "I will *now*", rather than "will not", below: "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 *now*." /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Charlie Arehart Sent: Wednesday, March 11, 2009 10:49 AM To: discussion@acfug.org 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 - 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 -
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 -
Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
I'm just dropping the argument, since its philosophical at this point. You are correct, not every app would be harmed, but it violates the principles of defense in depth if one of your defenses is so easily removed. -dhs Dean H. Saxe, CISSP, CEH d...@fullfrontalnerdity.com "[U]nconstitutional behavior by the authorities is constrained only by the peoples' willingness to contest them" --John Perry Barlow On Mar 11, 2009, at 11:52 AM, Charlie Arehart wrote: 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 - - 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 -
Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
A worthy discussion that show concerns that each of us need to keep in mind on this matter. Perhaps an agreement to disagree on the various points exemplified, shake hands and I buy the next round of drinks? Teddy R. Payne, ACCFD Google Talk - teddyrpa...@gmail.com On Wed, Mar 11, 2009 at 11:58 AM, Dean H. Saxe wrote: > I'm just dropping the argument, since its philosophical at this point. You > are correct, not every app would be harmed, but it violates the principles > of defense in depth if one of your defenses is so easily removed. > > -dhs > > > Dean H. Saxe, CISSP, CEH > d...@fullfrontalnerdity.com > "[U]nconstitutional behavior by the authorities is constrained only by the > peoples' willingness to contest them" >--John Perry Barlow > > > On Mar 11, 2009, at 11:52 AM, Charlie Arehart wrote: > > 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 >> - >> >> >> >> > > > - > 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 > - > > > >
Re: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
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 To: discussion@acfug.org 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: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 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 -
RE: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
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 -
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 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
RE: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
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 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 letti
RE: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side )
Yes, it's not quite clear whether you're responding to things Shane or I said, Jeremy. Just to be clear, I too was never arguing that client-side validation provided any security. It was the outlash against it--because it didn't help with that--which I was arguing against. As you say, it's valuable for user convenience and to save round trips, and that was my only contention. In other words, we shouldn't throw the baby out with the bathwater. And few would argue with the assertion that "validating the incoming data and protecting against incoming injection attacks is not all that difficult if you do it properly from the start." But Shane made a good point about how sometimes we can only propose what should be done. We can't always dictate what must be done. And for that reason, I'd argue that at least some client validation would be better than none at all. Sure, it won't stop a determined hacker, but really, not much will. But not everyone has something really valuable to protect. And like you guys have said, there's a sliding scale or the cost of protection against the value of the assets. Still, we could all definitely stand to know far more about the risks and the solutions, so that we can make informed decisions. And for that, we're really fortunate to have Dean Saxe on hand to keep us on our toes! :-) I really don't mean by any of my comments here to diminish the value and importance of the kind of security consulting he offers. /charlie -Original Message- From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Shane Sent: Monday, March 23, 2009 10:10 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] over-stating security concerns? (was RE: ValidateAt parameter is effectively only client side ) 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 - 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 -
