On Tue, Oct 18, 2011 at 10:34 AM, Gary McGraw <g...@cigital.com> wrote: > On 10/15/11 5:45 PM, "Steven M. Christey" <co...@rcf-smtp.mitre.org> wrote: >> 3) The wording about OWASP ESAPI in SFD2.1 is unclear: "Generic open >> source software security architectures including OWASP ESAPI should >> not be considered secure out of the box." Does Struts, mentioned >> earlier in the paragraph, also fall under the category of "not >> secure out of the box?" Are you saying that developers must be >> careful in adopting security middleware? > > Of course struts is not secure out of the box, which is the whole point of > the activity. The major difference between struts as insecure and ESAPI > as insecure is that ESAPI claims to be a secure solution, though it is > often not. One might argue that it is worse to claim to be secure and not > to be than to ignore the whole thing, but that's not really worth > pursuing. For more regarding Cigital's view on ESAPI, see > http://www.cigital.com/justiceleague/2011/09/24/suggestions-for-esapi-2-1-a > nd-beyond/
Gary, While I wholeheartedly agree with John Steven's championing that ESAPI be made enterprise ready, I think your characterization of John's blog entry of having anything to do with ESAPI "not being secure out of the box" is simply unfair. I did not see that listed as one of John's concerns about ESAPI. The closest way that one could make that association is that for most of ESAPI's security components there are no high level user stories / use cases to provide overall guidance on each component. And while that conceivably could cause security issues, I don't really see inadequate documentation as being the same thing as a being "insecure by default". While I think one could make the argument that ESAPI 1.4 was insecure by default (at least in the case of its symmetric encryption), I think that is an unfair assessment of the ESAPI 2.0 GA release. In fact, in some cases, we deliberately sacrificed backward compatibility (one of John's "enterprise readiness" criterion) with the 1.4 release compatibility because the development team's preference to choose security over backward compatibility. (Which is something that I believe is the right decision for security APIs.) This is not to say that the security in ESAPI 2.0 is perfect. In fact, the configuration issus is one of my nits to pick with ESAPI. Not only is it overly complex, but it does not allow an enterprise's operations team to lock down ESAPI properties in accordance with company security policies. But IMNSHO, I think that it does a far better job being secure-by-default than does Struts, which is the other API that you explicitly mention. Best regards, -kevin -- Blog: http://off-the-wall-security.blogspot.com/ "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents." -- Nathaniel Borenstein _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates _______________________________________________
