Stephen, I think this is very important and sage advice.
Philosophically, we do not want to bring developers to ESAPI, we want to bring ESAPI to developers. And that means working with where THEY are at and moving form there. I have not seen a large company use ESAPI directly in their code (although others may have). Due to the maturity level of ESAPI, I recommend that companies integrate ESAPI into their own corporate library to fill in the gaps (wrap it!). Everyone has a different nomenclature for function names, and I'm a fan of calling ESAPI.encodeForHTML() instead of ESAPI.encoder().encodeForHTML() which is what every "wrapper" has done so far, from what I've seen. > For the overlapping functions, I think that existing frameworks already do an acceptable job of _*providing authentication*_ I agree 100%. I do not see a big use case for ESAPI authentication in most large organizations - they usually have something like SSO or at least standard auth in place already. We need more maturity in this area. _* > , access control,*_ I think most frameworks get this wrong - in particular, I feel role based access control is basically a design (or even security) anti-pattern - and we need to move towards contextual/activity based access control. I am not saying that ESAPI is there yet either, but Access Control is an area that merits a great deal more research. _* > data validation*_ I mostly agree - but keep in mind that most frameworks do NOT do canonicalization, a crucial validation step. ESAPI does this better than the average bear. _*> and logging, *_ ESAPI provides something that log4j and others do not - security specific logging. It's not groundbreaking - it's quite simple. But very crucial, IMO. logger.error(Logger.SECURITY_FAILURE, "Attempt to add unsafe data to cookie (skip mode). Skipping cookie and continuing."); * > 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.* I'd like to rephrase that a little "Stick with your frameworks, but use ESAPI to fill in the gaps" Thanks for your thoughts, Stephen. I "get" where you are coming from, and I think your head is in the right place. (About this topic, at least ;) Regards, - Jim > 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. > _______________________________________________ >
_______________________________________________ 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. _______________________________________________
