[Owasp-topten] In reply to a few comments

Olivier Arteau olivier.arteau at owasp.org
Thu Apr 13 04:14:19 UTC 2017


I initially replied with my personal email instead of this email and the
reply doesn't show up. This might get duplicated.

> The OWASP Top 10 - 2017 data call data and some basic analysis of it is
available in this folder on github:
> https://github.com/OWASP/Top10/tree/master/2017/datacall. It's a simple
multi-tab Excel spreadsheet.
>
> -Dave

I honestly fail to see how this dataset supports the addition of A7 and
A10. There's no question or entry point in regards to any of the points
that A7 and A10 are supposed to address. Can you elaborate on how those
conclusions where made ?

> d) To an extend, I don't think developers should worry much about DDoS attacks.
Other tools are there for that.

I'm not sure if this is in reply to my previous comments. But I'd like to
point that *some* DoS (not DDoS) vulnerabilities are due to poor software
coding and developers should be aware of those when developing application.
A good example of this are "accidentally quadratic" algorithm that can make
endpoint take few minutes to respond with specially crafted arguments. An
other good example of this is server-side image processing that doesn't
properly limits the resources it uses. Specially crafted image can make
image processing tool take an absurd amount of RAM, disk I/O or CPU. The
list could honestly go on and on.

> If we can block attacks after the first few probes, it becomes much
harder for an attacker to find vulnerabilities they can actually exploit.
This makes such a capability a very helpful active defense.

You also have to keep in mind that building such aggressive features also
impact normal user. No tool or product can have the pretention to correctly
distinguish normal traffic and abnormal traffic without any false positive.
Also, from what I'm seeing, the usage of WAF or other similar blocking
product tends to bring a false sense of security. I have seen project
manager think that using a WAF will magically stop making thing
exploitable. If your application is swiss cheese, it's going to get
exploited whether you have WAF or not. Also, this active blocking approach
isn't something that's unanimous among the security community and there's
as far as I know no data that suggests it's worth the time and effort to
put in place in the long term. If you have this kind of data, please share
it. Given that the Top 10 is now a highly referenced guide, I think should
base itself on solid data instead of perception and anecdotal data point.
Those are the main issues that I have with the recommendation of *active
blocking tools*.

> Network security guys have been doing intrusion detection, intrusion
prevention, and quick patching for years. Our apps are going to be attacked
and compromised (no one can build perfect security). So, we need active
defense and the ability to fix things quickly.

As I and other mentioned previously, this is completely out-of-scope of
what a developer can do. The problem that I see with these new additions is
that the guide tries to address security issue that are totally unrelated
to developer job and their range of action. This guide has always been for
developer, it's not for manager. While recommending sane security practice
through out the SDLC is a good thing, it's just not the place in this
guide. There's other OWASP project like ASVS where requirements like
"logging security relevant information" are a much better fit to be
introduced. The Top 10 is about software vulnerabilities not management
practice or specific software security requirement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170413/bb8eb171/attachment.html>


More information about the Owasp-topten mailing list