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

Jim Manico jim.manico at owasp.org
Sat Nov 21 22:00:34 UTC 2015


Legacy needs: You need secure coding libraries

Highly custom and complex applications: You will often need to build access control and authentication layers yourself

Greenfield apps: By choosing prudent and recent frameworks, you'll get a combination of built in security API's and automatic security defenses built in, depending on the framework

I think we can push in all of these directions, based on the bottom up desires of our volunteer corp. These activities are already underway at OWASP in some respects.

I think focus is good, but it's up to the will of individual volunteers as our organization stands now. My question is, should we be spending money to hire folks to focus on some of these goals?

My opinion is : Lets spend money to hire or bounty serious developers to build automatic defenses, where we can, in popular frameworks. :)

Aloha,
--
Jim Manico
Global Board Member
OWASP Foundation
https://www.owasp.org
Join me in Rome for AppSecEU 2016!

> On Nov 21, 2015, at 3:28 PM, Bev Corwin <bev.corwin at owasp.org> wrote:
> 
> 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/83623eb6/attachment.html>


More information about the OWASP-Leaders mailing list