[Owasp-topten] OWASP Top 1- 2017 RC1

Dave Wichers dave.wichers at owasp.org
Wed Apr 19 14:31:18 UTC 2017


There have been numerous questions in various places around the rationale
for adding A7 and A10 to the 2017 RC. Fair questions, and we’re really glad
that there’s interest and passion about appsec. Here's some background on
how a new T10 is produced:

First off, the data call is only one source of input to an update of the
Top 10. It helps us understand if anything significant is happening in the
prevalence of the existing Top 10 risks plus of course are there any new
issues that are rising in prevalence. We are particularly interested in any
type of new issue we aren't well aware of. Most of the newer issues are
already in the "Additional Risks to Consider" list at the bottom of the 2nd
to last page of the T10 and its frequently one of those that moves up into
a new T10. Other sources of input are the answers to the questions asked of
the data providers, the experience of the Top 10 team, and our interactions
with the OWASP community and the AppSec community at large.

Based on this input, we develop what we feel are the Top 10 Risks to Web
Applications that application owners currently face today. Over the years,
we have frequently introduced new Top 10 items that deserved to be in the
Top 10, even though the vulnerability prevalence data didn't agree. For
example, CSRF was added to the 2007 Top 10 even though the data reported
its prevalence as 32. Three years later, CSRF was indeed a Top 10 most
prevalent issue, partially we believe because of the attention to this risk
that the T10 generated (which is a good thing!). Similarly, in the 2013
update, the Top 10 added "Using Components with Known Vulnerabilities", and
the 2017 data call shows that this issue too is now being reported as a Top
10 risk (by prevalence).

So why did we add A7 and A10?

A7 started with the data that Insufficient Anti-automation was being
reported more frequently. We don't think that this issue is particularly
new, nor is the fact that its being reported more indicate this risk is
more prevalent. We think its indicative that people should and do care
about this risk more, so organizations are willing to spend time looking
for and reporting such issues; and putting defenses in place. There are
also both old and new OWASP projects on this topic such as OWASP AppSensor
and the new (and fantastic) Automated Threats to Web Applications project:
https://www.owasp.org/index.php/OWASP_Automated_Threats_to_Web_Applications.
However, the project felt that the risk was beyond Insufficient
Anti-automation, but rather insufficient defenses against attacks in
general, which is why we generalized the name of this risk to:
"Insufficient Attack Protection". We think this category should cover:
Insufficient attack detection, insufficient attack response, insufficient
defense against automated threats, and insufficient ability to patch
quickly.  We were actually concerned that people would solely focus on
Insufficient Anti-Automation so we dialed back our focus on that in the
writeup to such a degree that, to some people, it appears to be completely
missing from this category, which was not our intent and we need to fix
that.

A10 was added to raise awareness that the use of APIs is exploding, and
deserves special attention to protect them properly. We understand that
this new category overlaps with all the other items in the T10 and that's
OK. The whole purpose of the T10 is to raise awareness of the Top risks to
web applications today and the project feels that this topic deserves some
sunshine and focus on this new trend in web development.

Philosophically, we’re not trying to create a strict taxonomy or make sure
that the Top 10 don’t overlap. Risks often overlap with each other and
that’s okay.  As an awareness document, we’re trying to focus on attention
to issues that affect large numbers of companies.  We don’t choose the
names of the Top 10 based on a formula or to keep them parallel. Instead,
we try to choose terms that are easy for organizations to latch onto and
investigate in their program. That said, we’re very open to new ideas about
naming these new additions to make them easier to understand and use.

We recognize that these new items aren’t exactly in line with what’s been
in the Top 10 previously.  But issuing yet another version of exactly the
same thing isn’t very interesting or provocative.  So we’re trying to
expand the scope of the T10 to reach beyond just development, and look at
some operational aspects of appsec.

-Dave

On Mon, Apr 17, 2017 at 1:02 PM, Colin Watson <colin.watson at owasp.org>
wrote:

> +1 too regarding A10
>
> On 16 April 2017 at 13:40, Aaron Weaver <aaron.weaver2 at gmail.com> wrote:
>
>> Hi Dex - The data is in the github repo - https://github.com/OWASP/Top
>> 10/tree/master/2017/datacall
>>
>> +1 on A10
>>
>> On Sun, Apr 16, 2017 at 7:51 AM, dex black <dexblack254 at gmail.com> wrote:
>>
>>> Greetings All.
>>>
>>>
>>> I read this update with some dismay; specifically in regards to the two
>>> new items.
>>>
>>> A7 Insufficient Attack Protection
>>> It seems a little odd to call a lack of attack detection code a
>>> vulnerability.
>>> The demonstrable need for such code varies wildly with the type of web
>>> site and therefore doesn't pass the test of general applicability.
>>> Perhaps when/if such code becomes more common place and turns out to
>>> have security flaws of its own we might return to this category of
>>> vulnerability. In all likelihood site administrators may become vulnerable
>>> to hubris around the efficacy of their COTS/homegrown attack detection
>>> solution(s); or worse yet some attack detection solution itself becomes an
>>> attack vector.
>>>
>>> A10 Underprotected APIs
>>> Cognisant of the fact that web APIs are a burgeoning area of development
>>> does not mean that the API itself, as a whole, is a vulnerability.
>>> When looking closely at the details of this item we see the same issues
>>> as always.
>>>
>>> 1. Ensure that you have secured communications between the client and
>>> your APIs.
>>> == A5 – Security Misconfiguration
>>>
>>> 2. Ensure that you have a strong authentication scheme for your APIs,
>>> and that all credentials, keys, and tokens have been secured.
>>> == A2 – Broken Authentication and Session Management
>>>
>>> 3. Ensure that whatever data format your requests use, that the parser
>>> configuration is hardened against attack.
>>> == A9 – Using Components with Known Vulnerabilities
>>>
>>> 4. Implement an access control scheme that protects APIs from being
>>> improperly invoked, including unauthorized function and data references.
>>> == A4 – Broken Access Control
>>>
>>> 5. Protect against injection of all forms, as these attacks are just as
>>> viable through APIs as they are for normal apps
>>> == A1 Injection
>>>
>>> What is the justification for repackaging or reclassifying these as a
>>> single unit?
>>> It seems to obfuscate the clarity of the existing list more than
>>> anything else.
>>>
>>> Bundling A4 and A7 together to make room for A10 probably isn't worth
>>> the cost in terms of altering training materials, certification assessment
>>> criteria, tooling and reporting.
>>> It might make a little sense due to ongoing confusion about the specific
>>> classifications.
>>> IMHO that still doesn't justify the proposed A10 Underprotected APIs.
>>>
>>> I also second a previous posting regarding transparency around the
>>> decision process.
>>> May we see the data?
>>> Has the threat and vulnerability landscape really changed much within
>>> the scope of web based technologies?
>>>
>>>
>>> Regard
>>> David 'dex' Schwartz
>>>
>>> _______________________________________________
>>> Owasp-topten mailing list
>>> Owasp-topten at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/owasp-topten
>>>
>>>
>>
>>
>> --
>> Aaron Weaver
>> Philadelphia OWASP Chapter Lead
>> OWASP AppSec Pipeline Lead
>> https://www.owasp.org/index.php/OWASP_AppSec_Pipeline
>>
>>
>> _______________________________________________
>> Owasp-topten mailing list
>> Owasp-topten at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-topten
>>
>>
>
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170419/7246307b/attachment-0001.html>


More information about the Owasp-topten mailing list