[Esapi-user] Stephen on ESAPI
jeff.williams at aspectsecurity.com
Mon Jan 11 00:04:49 EST 2010
Maybe we haven't always been as clear as we could be about this...
It's always best if developers can work within their framework. The
ESAPI project is trying to build some foundational security controls so
that developers don't have to keep remaking the same mistakes over and
over. If your framework already provides a control already, great. If
your framework wants to use ESAPI and hide it from the developer, great.
In some cases, the framework might want to expose ESAPI, and that's fine
Sometimes, you may want to integrate ESAPI into your framework's
existing security control. Generally this isn't too hard. If you want to
use Struts Validators, for example, you can write a custom validator
that delegates to an ESAPI validator. This allows most developers to use
the Struts pattern as normal, but you get the advantage of
canonicalization and intrusion detection under the hood.
From: esapi-user-bounces at lists.owasp.org
[mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Jim Manico
Sent: Sunday, January 10, 2010 2:52 PM
To: esapi-user at lists.owasp.org; 'Stephen de Vries'
Subject: [Esapi-user] Stephen on ESAPI
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. Also, 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. (ie: YOUR
ESAPI leveraging OWASP ESAPI).
> 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 authN classes in place already. We need more maturity in
> , 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
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
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
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,
implementations would replace the ESAPI reference
that is obviously going to take some time. I don't think that
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
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.
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.
Secure Coding mailing list (SC-L) SC-L at securecoding.org
List information, subscriptions, etc -
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC
as a free, non-commercial service to the software security community.
OWASP Podcast Host/Producer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Esapi-user