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

Jim Manico jim.manico at owasp.org
Sat Nov 21 19:34:14 UTC 2015


My thinking is facilitating *automatic* security additions where we can. 
Think Go templates, AngularJS or ReactJS (just use them and they 
autoescape), working with frameworks to turn on CSRF protection *by 
default*, or default security response headers that we see in RoR *by 
default*.  There is no way we can win every security battle in this 
fashion, but there are many security additions that frameworks can embed 
and enable for all. I think there is a lot of work we can do in this area.

And one more note - this is a great conversation. This is the kind of 
stuff I hope we as a community talk about (and do) more. It's central to 
our mission.


On 11/21/15 1:27 PM, Kevin W. Wall wrote:
> On Fri, Nov 20, 2015 at 10:00 PM, Jim Manico <jim.manico at owasp.org> wrote:
>> On Nov 20, 2015, at 4:10 PM, Tim Morgan <tim.morgan at owasp.org> wrote:
>>> Does this resonate with anyone?
>> Spot on. It's hard work and takes a lot of selfless dedication.
> 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 feel OWASP should consider spending some of it's funds to hire developers
>> to be dedicated to some of these tasks. Or offer bounties for specific
>> platform security tasks. I think that would accelerate this kind of
>> activity, significantly....
>> Auto-escaping templates, CSP integration, solid ABAC implementations,
>> default secure headers, solid integrated password storage, etc etc all by
>> default all integrated into common development platforms.
>> I think this would be an awesome way to serve the mission. Anyone agree?
> This idea sounds good in practice, but there already are many good security
> libraries (e.g, Spring Security, Apache Shiro, Struts validation, etc.)
> that are available to the development community but that most of the
> development community just fails to use. A great example of this failure
> that I've run across time and time again are applications that are already
> using Spring 3.2 that could enable Spring Security's CSRF protection in one
> additional line of their Spring config file (typically applicationContext.xml):
>       <csrf />
> between the <http>...</http> tags. (In Spring 4.x, CSRF protection is enabled
> by default.) Sure, like most things, it's not perfect, but is
> generally good enough
> to effectively mitigate these attacks. Yet, I seldom see this used. Even more
> strangely, when I do see CSRF protection mechanisms used via Spring 3.2,
> they more often than not are home-grown solutions.
> I could say the same thing for Struts validation. I very seldom see it used.
> So rather than trying to construct what we, as the security community, might
> think are better libraries or better approaches, I think we need to take a step
> back and research why the currently security libraries are not used more
> often.
> I do agree with Tim that a large part of the reason is that we don't see
> developers writing secure code is largely due to a copy-&-paste mentality
> to code. Developers google for something like "how do I do <x>?" and
> the first few links pop up something from Stack Exchange or W3Schools
> and the copy the first working example that they see and don't bother
> searching for a secure solution. Certainly a large part of this can be
> blamed on an unawareness on developer's parts that what they are
> 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.
> -kevin

Jim Manico
Global Board Member
OWASP Foundation

More information about the OWASP-Leaders mailing list