[Owasp-board] ESAPI - results
Kevin W. Wall
kevin.w.wall at gmail.com
Sat Jun 14 22:11:38 UTC 2014
On Sat, Jun 14, 2014 at 4:29 PM, Jim Manico <jim.manico at owasp.org> wrote:
> There are still major security bugs and design flaws in the current ESAPI
> for Java:
> 1) Singleton design leads to concurrency bugs
I've been one of the most vocal against the use of singletons used in
all the major ESAPI components, but I'm pretty sure that Chris and I
have fixed all the concurrency issues related to the use of singletons.
So I don't see THAT as the major issue here and certainly anyone
implementing a custom implementation of any of the ESAPI interfaces
of course does not have to use a singleton pattern to implement it.
In fact, in the code that I've not yet checked in, I've reimplemented
JavaEncryptor so that it no longer uses a singleton pattern. However,
let's be clear...I didn't do that for concurrency reasons. Instead, I did
if so I could have additional flexibility (e.g., so now you will be able to
have one JavaEncryptor using AES and another using DESede) and
to simplify testing (e.g., using Mock Testing is damn near impossible
with singletons, or at least an order of magnitude more difficult).
> 2) Poor use of random generation effects CSRF tokens and other areas...
I can fix this...I just can't fix it so that it is backward
compatible, especially in
terms of the default length of the tokens we are creating.
I plan on fixing this as part of the next point release; I'm just not
promising when that next point release will be. I have too much
other things going on with other things--some OWASP and some
> I could go on, see...
> ... for the 169 existing bugs recorded against ESAPI for Java.
> Can we make fixing at least some of these condition for flagship?
Out of those 169, I am only the owner of 7 of these. So a little help
would be appreciated.
And that brings me to this point... even if a project had ZERO bugs, I
don't think it should be a flagship product if there is only one person
contributing to it. Because in that case, despite what we call it, it's
no longer an OWASP project, but only a pet project of that individual.
Note that this does NOT mean that I am NOT intending to support ESAPI
the best that I can in the time I have available. But what should be realized
is that the support for it is not going to be up to the level of where true
OWASP flagship projects like ZAP should be.
I dunno why ESAPI can't seem to attract volunteers. Maybe writing
defensive software is not as sexy as writing software for breakers
like ZAP. Maybe there are less OWASP people in the builder
category. Maybe I just suck as an ESAPI evangelist. (I vote for the
last one, but on the other hand, IIRC, I didn't exactly volunteer for
Maybe it would help if the OWASP conferences could have a "call for
volunteers" for ESAPI. I only make it to maybe one conference a year
so that's not a position of great visibility. Some of you others rub
shoulders with several orders of magnitudes of OWASP members than
I do, so if you want ESAPI Java to survive, I am going to need some
NSA: All your crypto bit are belong to us.
More information about the Owasp-board