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

Bev Corwin bev.corwin at owasp.org
Sat Nov 21 21:28:47 UTC 2015


Hi everyone, All sound like good concepts to me. Is it possible to have
both, somehow integrated into best of both (or all) worlds, instead of
either / or scenarios only? Best wishes, Bev

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.
>
> 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.
>
> 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.
>
>
> 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.
>
>
> > >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.
>
>
> > >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.
>
> tim
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151121/2296d49b/attachment.html>


More information about the OWASP-Leaders mailing list