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

Kevin W. Wall kevin.w.wall at gmail.com
Sat Nov 21 23:46:14 UTC 2015


On Sat, Nov 21, 2015 at 4:16 PM, Tim <tim.morgan at owasp.org> wrote:
>
> Jim: you nailed it.  As you say, "built in" and "by default" are the
> key goals.
>
> Off-the-shelf third-party libraries that provide good security
> features (when you turn them on) are certainly necessary, but this
> misses the target audience I'm talking about.

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

> We need to fix the APIs developers are already using, and in
> particular we need to fix the APIs that a typical novice developer
> will try first.  If .NET provides a class to do X, then that's
> probably the first place a .NET developer will look (and examples on
> how to use it on random discussion boards) unless there's a good
> reason not to.

Back in the day, when Sun came out with the concept of deprecating old
or broken code through their @deprecation Javadoc annotation, I was hopeful
that that would be a mechanism that would force people to stop using
broken interfaces once they were marked as @deprecated after some
reasonable # of years and/or releases. In reality, it had zero impact
because 1) it was only a compile-time warning that had no effect on
the runtime (as long as the interface was still present in whatever jar),
and 2) Sun (and later Oracle) never had the balls to actually _remove_ any
of the deprecated interfaces. (IMO, it would have been more effective it at
least using deprecated interfaces would incur a large runtime performance
hit...doing something as simple as sleeping 1 second if a deprecated method
is used probably would have caused developers to actually fix things.)

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.

Now of course there are a few cases where (to use Tim's example) Microsoft
can modify the class that does X so that it is both secure and backward
compatibile, but that's not generally the case. In those cases, you either
need some alternate class or method within the class or break backward
compatibility. In the latter case, you would just get a lot of development teams
that would decide not to migrate to the new .NET framework (say).

So this is a tough problem. And because there's a much broader use of 3rd party
libraries than was used a dozen or so years ago, it's more pressing than ever.

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

> Why go through the trouble of learning a third-party library in
> addition to the language you're just now getting the hang of?  Of
> course there are reasons to do it, but remember, you're a novice
> developer.

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.

> Responding to Kevin:
>
>> >Agree with that. Writing good general security class libraries / APIs
>> >that developers
>> >find easy to use in widely different contexts that you can't completely
>> >foresee is extremely difficult. It requires both significant development and
>> >security experience relatively few have.
>
> I agree that, in the general case, we can't anticipate how all
> developers are going to use a given API.  But that isn't the point.
> We're after the common case, since the simple, common case is the one
> that can generates so many bugs.  Then we spend a decade trying to
> track down every last one of those bugs that could have been easily
> avoided.  Let's start by eliminating the common case mistakes and then
> spend our time working on more clever corner cases.

Okay, but sometimes it goes beyond the basic use case approach. Example, in
a previous life, my team developed a proprietary security library similar to
ESAPI. It had a (admittedly, poorly designed) BasicEncryptor class that
did encryption and when it was constructed, the CTORs would generate a
unique IV to use for encrypting. (It was ignored for decrypting as it was
expected that the IV was prepended to the ciphertext.) Since this class
library was to be used in web applications, there was an implicit, but
very wrong, assumption that developers would construct a new instance for
each encryption. (Fortunately, it used CBC mode the the breakage wasn't a
100% death blow like it would have been had we been using a streaming cipher
mode.) Instead, we discovered dev teams creating static instances of
BasicEncryptor so that all the encryptions used the same IV. The good news
was that we were able to fix it transparently by moving the IV generation
from the CTOR to the encrypt() methods (where admittedly, it should have been
all along). The only reason we were able to do this though was because the
overall design of BasicEncryptor did not expose IVs anywhere; we had wisely
intentionally hidded that notion.  So, that's the type of thing that I was
thinking. You need to think beyond the common use case method. A more common
example would probably be where there's an implicit assumption that an object
instance would be passed across different threads because there is not inherent
thread safety. That's something that's seldom documented in Java APIs. (One way
that perhaps we could draw attention to that is to lobby to introduce some new
Javadoc annotation like @mt-unsafe or whatever, but I digress.)

>> >I could say the same thing for Struts validation. I very seldom see it used.
>
> Ugg... Struts.  Yeah, don't use that.  Don't have time to justify it
> here, but Struts should be avoided if security is a concern at all.
> They took a useful platform and then introduced a bunch of RCE bugs.
> And they still haven't addressed the root problem with those RCEs,
> AFAIK.

True that, but when you have multi-million line legacy applications deployed
and using it, it's not going to go away. (See earlier Struts 1 --> Struts 2
discussion.)

>> >copying are insecure. So I don't really know how to combat that. Maybe
>> >rather than OWASP funding developers to work on security libraries, we
>> >should hire security conscious developers to patrol development forums,
>> >newsgroups, etc. and correct posts where examples are given that have
>> >security vulnerabilities.
>
> I agree that is an outstanding problem.  Hopefully if a platform's
> core APIs and documentation steer most developers down a secure path,
> then those making bad recommendations today on forums will start
> making better recommendations later....   But the issue certainly
> won't go away any time soon.

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?

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
NSA: All your crypto bit are belong to us.


More information about the OWASP-Leaders mailing list