[Owasp-leaders] Instead of OWASP libraries, why don't we ...

Tim tim.morgan at owasp.org
Mon Nov 23 21:10:53 UTC 2015

Hi Kevin,

Not responding to everything you said, but I did read it all. =)

> If you have to "turn them on" then obviously they are not secure-by-default.
> That's one point we need to emphasize.

Yeah, exactly.  And going out to find a secure third-party library to
do something for you implicitly means it isn't "on" by default.

> Anyway, why do I bring this up? Because without a mechanism to allow
> developers a *simple* migration path, you won't get developers to switch
> to the new version. To illustrate with the extreme opposite case, lot at
> everyone's favorite bogeyman, Struts 1.x. Major revisions were needed to
> applications for applications to migrate from Struts 1 to Struts 2. As a
> result, there are still many applications which large code bases that are
> still using Struts 1 even though it is unsupported and has many RCE
> vulnerabilities.

Right, makes sense.  And we probably won't be able to get every
developer to move off of the old, insecure APIs.  But we can at least
guide new applications and new developers down a safer path.  It does
work, BTW.  I have seen the number of XXE vulnerabilities in .NET apps
drop dramatically over the last 5 years.  .NET still supports legacy, 
vulnerable-by-default XML parsers, but all of the newer stuff that
they place front-and-center in their docs are secure by default.  It
does make a big difference.  By contrast, Oracle isn't anywhere close
to implementing this kind of proactive API security in Java.

> How do we address this? Good question. I do not know of any general way to
> do so, but maybe I'm overlooking something.

I think as we evaluate APIs, we should include a checklist item:
"Platform docs guide developers away from less secure and deprecated
APIs to safer ones."  If they don't do that, then they get dinged in
the rating.

> Assuming this was not a rhetorical question there are a couple of reasons
> that drive this:
>     1) you end up in a development shop where they are already using that
>        3rd party library.
>     2) developers believe that using it will help them developing code to
>        accomplish their business task at hand more quickly than not using it.
>     3) some developers just want something new and shiny to put on their resume.

Right, it happens.  And I wouldn't rule out approaching third-party
platform developers, like Spring/Struts/etc, especially if the core
platform doesn't provide an API for something everyone needs.  The
LDAP APIs are a good example of that, so I just analyzed the APIs that
came up first in google searches like "Python LDAP" and "Java LDAP".
But in a given area, I think we should start with whatever is most
likely to be used by novice developers for a particular task.

> But that almos assumes that the original implementers of that core API have
> a reasonable amount of security expertise. You might be able to do this for
> platform APIs like the JDK or the .NET Framework, but I don't see that as
> likely for most 3rd party platforms. And security folks don't gravitate to
> libraries like Apache Commons (to use a recent example in the news) until
> something bad is discovered. Where were we security people when these
> interfaces of these Commons-Collections classes were being originally designed?

Yes, that's an excellent point.  We need to start small in this effort
and get the framework in place that helps us make good
recommendations.  However, once it is in place, I think we definitely
should look at new, up-and-coming platforms and "head them off at the
pass", so to speak.  That is, try hard to catch these new whiz-bang
frameworks early and help them build better APIs before we end up with
a lot of less secure legacy implementations and technical debt.  The
hard part here is anticipating where to spend our time and energy...
Which new platforms will become the next fad?  That will take some
guesswork, but it is still worth trying for.

Thanks again,

More information about the OWASP-Leaders mailing list