[Owasp-board] ESAPI libraries-preliminary tests results

Josh Sokol josh.sokol at owasp.org
Fri Jun 13 14:49:55 UTC 2014

I had an interesting conversation with Mark Curphey while he was in Austin
this week and at one point we got to talking about ESAPI.  Personally, I
love the idea of having functions that you can call to ensure security of
your code, but it did get me wondering if the API approach was the best
one.  Thinking at a higher level, what if OWASP tried to foster
relationships with the companies and organizations who are actually writing
the languages themselves and tried to influence that way?  For example, we
could start talking with Oracle about Java security and try to contribute
directly to the security of Java itself, rather than trying to write an API
around it.  I would be happy to make an introduction to Milton Smith, the
Sr. Principle Product Security Manager at Oracle for Java.  He was involved
with OWASP Austin before moving to take the job with Oracle.  For .NET,
Mark said that he could make introductions to the right people at Microsoft
and I know Michael Howard, who would likely be happy to introduce us to the
right people as well.  In any case, what if we threw out the notion of an
Enterprise Security API entirely and instead tried to bake that
functionality directly into the product so that it was secure by default?
What do you think?


On Thu, Jun 12, 2014 at 8:44 PM, Kevin W. Wall <kevin.w.wall at gmail.com>

> On Thu, Jun 12, 2014 at 8:40 PM, johanna curiel curiel <
> johanna.curiel at owasp.org> wrote:
> > Hi Esapi Team members
> >
> > I have begin with the verification process of activity level in the ESAPI
> > libraries
> > based on the activity level I'll continue to create test cases for those
> > libraries that are been actively maintained or show a significance level
> of
> > maturity.
> >
> > From this preliminary tests I have checked and create tasks in JIRA for
> >
> > Perl==> Last maintained 3 years ago
> > C++
> > Python==>last release from 3 years ago
> > .NET==>last release from 3 years ago
> > C==>Source code last updated 2 years ago
> > Java
> > Classic ASP==>last release from 3 years ago
> >
> > The projects highlighted in yellow have a very low development activity
> but
> > also very little participation of the community.
> >
> > The other projects show a significant maturity level and activity.
> >
> > I must say that all of the ESAPI projects show a high level of code
> > development but the yellow ones are not been maintained in  along time.
> >
> > I would like to know if as project leaders, do you consider that these
> > (yellow) projects are indeed inactive?
> >
> > If that's the case, are you planning to revive  them in a close
> future(lets
> > say 6 months)?
> >
> > I'm trying to test effectively and a project that shows that does not fit
> > the preliminary health criteria cannot be consider a flagship project.
> >
> > If anyone has missed the mailing list regarding this I suggest to check
> to
> > check it here:
> >
> > https://www.owasp.org/index.php/Proposal_Project_Review_QA_Approach
> >
> > Please let me know your situation regarding these projects. It is
> essential
> > to determine the path of the further test plan.
> Hi Johanna,
> Truthfully, I think it is unlikely that any any of these various ESAPI
> projects, with the possible exception
> of ESAPI Java is ever going to be revived. Jeffrey Walton was mostly
> keeping the ESAPI C++ project
> alive but he was disillusioned with what he perceived as OWASP politics
> and decided to quit the project,
> which is a shame because he had made some excellent contributions to that
> and some of the
> OWASP cheat sheets.
> At one point about a year and a half ago, I thought there was a
> possibility of reviving the ESAPI .NET
> version. Someone had tentatively stepped up to work on it, but that too
> died out. Since that time, I
> think that having a ESAPI .NET implementation really doesn't matter very
> much anymore because
> the latest .NET Frameworks themselves have almost everything that ESAPI
> has (with the sole
> exception of support for authenticated encryption and a built-in WAF). It
> certainly is solid on the
> validation and encoding side where we saw about 90% of the ESAPI use
> occurring.
> Lastly, you probably should add ESAPI PHP to the list. There is also one
> for Sales Force (maintained
> by them) and one for Cold Fusion (which I think that Adobe might
> maintain). There's also a
> JavaScript version, but it mostly only does encoding and some validation.
> I've only been involved in the Java, C, and C++ versions however so I
> can't really comment on
> the others.  Chris Schmidt may be able to add more (CC'ing him as well as
> the ESAPI Dev list).
> -kevin
> --
> Blog: http://off-the-wall-security.blogspot.com/
> NSA: All your crypto bit are belong to us.
> _______________________________________________
> Owasp-board mailing list
> Owasp-board at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-board
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-board/attachments/20140613/88c8d03a/attachment.html>

More information about the Owasp-board mailing list