Friday, March 28, 2014

ESAPI No Longer an OWASP Flagship Project

I read the news today oh, boy…

By now, you’ve probably heard about several of the OWASP board members (and perhaps, some bored members as well) coming to the conclusion that several of the current OWASP flagship code projects should be demoted and others should take their places. (If you’re not up on the news, you can read about it in these 3 email threads archived here, here, and here.)

Among the flagship projects suggested for being demoted is OWASP ESAPI, of which I am the project owner for the Java implementation.  After hearing about the recent ESAPI Hackathon, you may be puzzled or perhaps even surprised by this news. You shouldn’t be. While it may sound like heresy coming from an ESAPI believer, although I am not happy about it, I think this action is long overdue and is best for OWASP. So I guess I’m sorry if I disappoint those of you who are ESAPI fans because I’m not standing up for ESAPI and defending it, especially since it's not yet a done-deal.

I’m not, because I can’t. I, for one, can see the writing on the wall. (Pun intended.) All of the allegations that are being made against ESAPI are spot-on:
·         Only one minor point release in since July 2011.
·         164 open issues, including 4 marked Critical and 11 marked as High.
·         Far too many dependencies, something that has never been addressed despite being promised for almost 3 years.
·         Wiki page still in the old OWASP format.
·         Minimal signs of life of for ESAPI 3.0 in GitHub and ESAPI 2.x for Java on Google Code. Zero signs of life for implementations in other programming languages. [Note: Discounting the SalesForce one as I’ve not kept track of it.]
·         For ESAPI for Java, a boogered up architecture where everything is a singleton making some things such as mock-testing all but impossible. Less than 80% test code coverage, in part, because of that.
·         Lack of any significant user documentation outside of the Javadoc and the ESAPI crypto documentation.
·         Disappointing participation at the ESAPI Hackathon.

I could go on, but I won’t.

ESAPI has dropped the baton and I’ll take as much blame for that as anyone. I have neither the contacts nor the people skills needed to entice developers to participate in ESAPI. Of the 3 or 4 people that I have recruited at one time or another, they’ve not contributed to even a single bug fix. And it goes beyond that. I’ve still not yet put together a release based on the few updates (a couple minor bug fixes and a small enhancement in handling configuration files) that were done by those participating at the ESAPI Hackathon. I have also still yet to release a fix for CVE-2013-5960. (Aside: Hey! Could use a little help here! Ideally someone who knows a thing or three about crypto.)

It’s time that ESAPI yield the baton to some of the other worthy candidates like OWASP HTML Sanitizer, OWASP Dependency Check, and OWASP Java Encoder to name just a few.

What does this mean for ESAPI support?

Well, probably nothing. I mean, honestly, the support really hasn’t been that great in the past 3 years. I do suspect that it might radically give those thinking about adopting it for a new project a reason to rethink that commitment though.

I will personally commit to trying to fix any known bugs in the ESAPI crypto (including a few you didn’t even know were there; well, okay, maybe “annoyances” would be a better tem), including a fix to CVE-2013-5960. But I am likely through with any planned feature enhancements other than the minor ones that I’ve been working on. If I do any further enhancements for the crypto features, I will split off ESAPI Crypto into its own new incubator project. No more promises of time frames though. I work a 40+ hour job like most of you and the ESAPI work is volunteer hours and I have family and other commitments as well.

As for ESAPI 3, will it flourish or die out before it even gets started? Well, that’s up to you, OWASP Community. I certainly am a believer in the ESAPI concept of a common set of interfaces for common security controls, but the problem has always been the implementation, not the concept. As they say, the devil is in the details.

So if you want to volunteer to work on ESAPI, give us a shout out on the ESAPI-Dev list. If you aren’t already signed up, you can sign up here.

Best regards,
-kevin

6 comments:

  1. I completely agree, and kudos to you Kevin for taking this position

    ReplyDelete
  2. Kevin, thanks for writing up the facts so clearly and accurately. I deeply appreciate all the hard work that you have put into the project over the past years. With over 5000 companies currently using ESAPI, and getting it included in Adobe ColdFusion and Force.com, ESAPI has influenced a lot of developers and has done a lot of good.

    ReplyDelete
  3. I agree, the concept and much of the implementation of ESAPI is excellent. But there are critical security bugs within. The crypto still has a major outstanding issue CVE-2013-5960 and the random number generation is broken since it uses the same instance of SecureRandom as a singleton. So for the 5000 companies using ESAPI-Java for crypto, random number generation or CSRF protection, you are not getting the protection you think you are getting. Ouch!

    ReplyDelete
    Replies
    1. IMO, CVE-2013-5960 is not has bad as NIST made it sound. I tried to tell them that this is only an issue if someone is using some non-default, seriously weakened properties as to what cipher modes are allowed. If you are using the defaults, this should not be a problem unless someone is able to get you to change them by some social engineering. OTOH, I'm not saying that is an issue, but rather IMO NIST way over estimated the CVSSv2 score. IIRC, the one that I originally submitted them came out to something like 4.7 or so. They changed it without telling me and then never responded when I tried to explain why it should be lower. Whatever!

      As far as SecureRandom as a singleton, and/or not being reseeded, yes that is potentially an issue, but not nearly as major as it is made to sound. If you are calling SecureRandom a few quintillion times or so, perhaps, but I suspect that most applications get restarted long before that becomes an issue.

      Delete
  4. Luckily, Force.com and ColdFusion do not use the ESAPI for Java *default implementation* they just use the interface. If they used the java implementation, ESAPI would cause mass insecurity as described above across all of those ecosystems.

    ReplyDelete
    Replies
    1. Let us hope that Force.com and ColdFusion versions of ESAPI do not use the badly broken ESAPI 1.4 interfaces and configuration for their crypto. (Assuming they even support crypto; I've honestly never looked at those implementations so I can't say.) Is so, they they might be worse off in some manner.

      Delete