[Owasp-board] ESAPI - results

Jim Manico jim.manico at owasp.org
Sat Jun 14 22:48:21 UTC 2014


I see this as not about you or me and I'm not trying to put pressure
on you. I just want to be honest to the user community about the
quality of our projects. That's it. ESAPI makes a fine labs project,
and I have no problem leaving it there if you and others do not have
time (or support) to fix the bugs.

Jim Manico
(808) 652-3805

> On Jun 15, 2014, at 6:11 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:
>> 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
> family.
>> I could go on, see...
>> https://code.google.com/p/owasp-esapi-java/issues/list?can=2&q=&sort=priority&colspec=ID%20Type%20Status%20Priority%20Milestone%20Component%20Owner%20Summary
>> ... 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
> the position.)
> 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
> help.
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/
> NSA: All your crypto bit are belong to us.

More information about the Owasp-board mailing list