[Esapi-user] Recommending ESAPI?

[jim at manico.net (Jim Manico)]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://krvw.com/pipermail/sc-l/attachments/20100110/c775e62c/attachment.htm>