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.
_______________________________________________

Reply via email to