[Owasp-leaders] Instead of OWASP libraries, why don't we ...
jim.manico at owasp.org
Sat Nov 21 20:20:12 UTC 2015
Dinis talked about building a test suite for ESAPI and other security
libraries that would cover this basic need. I think it's a very good
idea. It will take a group of pros to pull this off, but if anyone has a
charge over this, please go for it.
By the same token, the efforts of those building defensive libraries at
OWASP are still very valid. I'm quite fond of the quality of AppSensor,
the OWASP Java Encoder and the OWASP HTML Sanitizer in particular. I
also think Dependency Check and ZAP while not defensive libraries, are
still examples of an OWASP tools that are production quality.
OWASP is of course bottom-up. I do not want to discourage those who have
put so much effort into very important and powerful OWASP projects.
So to me this is not "one or the other" but both.
On 11/21/15 2:06 PM, Josh Sokol wrote:
> Something that I've also mentioned to Jim in the past is that this
> concept of individuals working on individual projects will only take
> us so far. As an organization, we need to come up with standard
> function names, inputs, outputs, error reporting, etc across different
> languages and frameworks. That way, as an organization, in our
> documentation we can reference something like "For HTML output
> encoding, use the encodeHTML" function and it doesn't matter which
> language they are working with, the process is the same.
> On Sat, Nov 21, 2015 at 1:34 PM, Jim Manico <jim.manico at owasp.org
> <mailto:jim.manico at owasp.org>> wrote:
> 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 <mailto:jim.manico at owasp.org>> wrote:
> On Nov 20, 2015, at 4:10 PM, Tim Morgan
> <tim.morgan at owasp.org <mailto:tim.morgan at owasp.org>> wrote:
> Does this resonate with anyone?
> Spot on. It's hard work and takes a lot of selfless
> Agree with that. Writing good general security class libraries
> / APIs
> that developers
> find easy to use in widely different contexts that you can't
> 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
> 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
> <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
> 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
> and the copy the first working example that they see and don't
> 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.
> Jim Manico
> Global Board Member
> OWASP Foundation
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
Global Board Member
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders