On Jan 10, 2010, at 5:38 AM, Kevin W. Wall wrote: > > IMO, I think the ideal situation would be if we could get the Spring and > Struts, > etc. development communities to integrate their frameworks so that they could > be used with the ESAPI interfaces. (In many of these cases, these > implementations would replace the ESAPI reference implementation.) However, > that is obviously going to take some time. I don't think that the ESAPI > dev team can do it all.
I think this is overestimating ESAPI's place in the pecking order. Spring and J2E already have well established APIs for important security functions with a _lot_ of developers already invested in these APIs. A better approach would be for ESAPI to adapt its API to suit Spring and the other frameworks. To touch on one of Dinis' questions, my advise would be for developers to use the features from their existing frameworks and only use ESAPI for the gaps. I confess to not having used ESAPI (just scanned the API), but from what I know of other frameworks some of the gaps that ESAPI might plug would be: - Output encoding in funky places, like JavaScript and CSS (Some apps never need this) - CSRF protection (Sometimes the pageflow/workflow features of a framework will already give you CSRF protection, if not, then ESAPI) - Intrusion detection (if the level of assurance demanded by the application requires it) - Some methods from the HttpUtilities class could be useful (e.g. setNoCacheHeaders, setSafeContentType) For the overlapping functions, I think that existing frameworks already do an acceptable job of providing authentication, access control, data validation and logging, so unless there's a compelling feature that the application needs from ESAPI, I'd advise them to stick with their investment in their existing frameworks. Stephen _______________________________________________ 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. _______________________________________________