Wednesday, April 2, 2014

My thoughts on the inevitable ESAPI demotion

So I have taken a few days to think about the upcoming demotion of ESAPI as an OWASP flagship project - see here.  Now I am not sure if my thoughts on this are based from what I read in the announcement and email threads or if I came to this thought on my own.  Regardless, I'm not looking for credit, just wanted to express my thoughts and how this may effect ESAPI4CF.

I feel ESAPI is still a viable project for sure.  It packages the tools to secure your web application in a nice and tidy bundle so everything is at your disposal.  It integrates some of the modules, particularly the Authenticator/CurrentUser with the Logger and each module uses the Logger therefore logging not only the security message, but the user data along with it - this is one of my favorite parts of it.

However, perhaps ESAPI bit off more than it could chew.  Each module of ESAPI tends to have a different focus from authentication, access control, encoding, encryption, logging, etc.  Each of these areas tends to have a different knowledge expert.  Security is far too important to be addressing all of these areas as a "jack of all trades, master of none".  The masters are the ones that need to be involved with each module.

I did see the idea somewhere in that news of splitting the viable ESAPI modules off into their own OWASP projects.  I believe the term that was used was "salvaging" ESAPI - possibly applicable.  I see this as a great idea!  There is already the Java Encoder and Java HTML Sanitizer projects and these could both easily be used in place of the ESAPI Encoder and the ESAPI Validator is/getValidSafeHTML() pieces respectively.  This, I know, was mentioned in the threads somewhere.

However, let's take a another look here.  I agree that breaking the ESAPI modules off into their own projects, with each their own leads, contributors, knowledge experts, is a great idea.  They will each get the focus they well deserve.  But let's not disregard ESAPI itself.  It brings all the security tools together and I don't think that should change.  What I am saying is, instead of the ESAPI project creating each module as part of its project, change ESAPI to include other projects as part of its library.  ESAPI could then focus on integrating the modules and providing the pieces which are not in individual projects.  It could be the glue that brings the OWASP projects together.

ESAPI essentially does this already with the Validator is/getValidSafeHTML() methods which leverage AntiSamy under the hood.  So replacing this one should be fairly straightforward - rip out AntiSamy and replace with the HTML Sanitizer.

As for the Java Encoder, the underlying classes to the ESAPI Encoder module could all be dropped and the DefaultEncoder guts replaced with calls to the Java Encoder.  Easy enough!

In fact, ESAPI was architected to provide "DEFAULT" implementations of the interfaces, so you don't even have to wait for the project to do this - create your own implementation doing exactly this!

Encryption is a big one and I did see it mentioned how this should become its own OWASP project and I wholeheartedly agree with that statement.  That is a complex beast best left to the masters. I welcome seeing this as its own project if it is not already (in case I missed that announcement).

Now there are modules like the Authenticator and AccessController that I don't really see being their own projects which is also fine.  I could be wrong, perhaps there is justification for them being a separate project but I'll leave that decision to those smarter than myself.  Even without their own project, these could still be key components to the ESAPI project and the integration with the other modules.

Anyway, just my thoughts on the announcement.  Personally, I feel that I may not wait for a decision or direction.  I will most likely move forward with changing ESAPI4CF's Encoder module and Validator is/getValidSafeHTML() methods over to the Java Encoder/Sanitzer projects in the next development cycle.  Why?  Cause I think its a great idea and will only help make the ESAPI4CF project better.