[Owasp-topten] RC feedback - Missing "Lack of anti-automation"

Colin Watson colin.watson at owasp.org
Fri Apr 28 10:30:44 UTC 2017


Just to contribute a little more to these thoughts, Dave W has noted that
A7 is meant to include four main issues:

1. Insufficient attack detection
2. Insufficient attack response
3. Insufficient defense against automated threats
4. Insufficient ability to patch quickly.

The OWASP Automated Threats to Web Applications is completely vendor and
technology agnostic. Although there are overlaps, it primarily addresses
the third issue above, and the project mapped out threats to 5 WASC
weaknesses/attacks, and 9 or so CAPEC attack patterns. In 2015 we created
two diagrams to illustrate the relationships:

https://www.owasp.org/images/e/e8/Ontology-chart-wasc-wiki.png

https://www.owasp.org/images/8/8e/Ontology-chart-capec-wiki.png


The countermeasures we propose include many things that architects,
designers, developers and testers should tackle. "Defense" should not be
seen as a bolt-on afterthought.

Our project is drafting some suggested wording changes to A7 that try to
indicate it includes all these 4 types of issue.

Colin




On 26 April 2017 at 01:20, Sumit Agarwal <sumit at shapesecurity.com> wrote:

> All,
>
> I agree with Colin. I believe A7 should be modified to address this
> specific point:
>
> >* Our project's unwanted automated usage are not about exploitation of
> *>* vulnerabilities, but instead often relate to misuse of inherent valid
> *>* functionality. *
>
> Attacks like credential stuffing don't rely not on exploiting a
> vulnerability - they misuse legitimate functionality intended for human
> users. In addition, while these attacks can be performed manually (i.e.
> someone can run through a list of 10 or 100 credentials by hand) the
> primary mechanism requires automation in order to achieve scale and create
> significant damage..
>
> I submitted data about automated threats in partnership with a pen testing
> firm last year to raise awareness of this issue. Automated attacks are
> incredibly widespread. We sit inline with over 200M web transactions per
> day going primarily to F500 websites, and we regularly find 50-80% of total
> traffic is automated. We would be happy to set up a call with interested
> parties to share these or other related datapoints.
>
> In terms of specific language for A7, I suggest something that
> incorporates some of the language from the WASC Wiki:
>
> *"Insufficient Anti-automation occurs when a web application permits an
> attacker to automate a process that was originally designed to be performed
> only in a manual fashion, i.e. by a human web user.*
>
> I also have in mind the description on the OWASP OAT page:
> "Web applications are subjected to unwanted automated usage – day in, day
> out. Often these events relate to misuse of inherent valid functionality,
> rather than the attempted exploitation of unmitigated vulnerabilities."
>
> With that in mind, I propose minor tweaks as follows:
>
> "The majority of applications and APIs are insufficiently protected
> against automated attacks against valid functionality. Attack protection
> goes far beyond basic input validation and involves the ability to
> recognize, log, and mitigate automated use of otherwise legitimate
> functionality. Application owners need to be able to deploy patches quickly
> to protect against new automated attacks."
>
> Changes and rationale for changes:
>
> -- inclusion of word "automated" and removal of word "manual". Having both
> of those words is not much different from saying "all attacks". The unique
> and noteworthy attribute of these attacks is that they use legitimate
> functionality via automated means. A credential stuffing attack (for
> example) is not economically feasible without automation. With automation,
> it is highly effective and highly profitable.
>
> -- addition of "valid functionality" and "otherwise legitimate
> functionality". As many have pointed out, this category goes beyond
> tradition vulnerabilities, for which the word "exploit" is more suited, and
> includes attacks that do not actually 'exploit' anything in the traditional
> sense. The attacker is making use of legitimate functionality exactly as
> legitimate users would, and at the level of a single transaction, nothing
> is obviously wrong with the request. A whole new set of questions/answers
> are required to identify a malicious login request which is part of a
> credential stuffing attack. The data being submitted are not malicious
> (just another set of credentials). It is the mechanism by which they are
> submitted (via automated means, perhaps using a large distributed botnet)
> which might help application owners determine that the submission of
> credentials is part of an attack.
>
> *Note: I focused on credential stuffing because it extremely prevalent in
> practice, affects anyone who has a login form, and captures the core issues
> nicely. There are obviously many other important automated attacks which
> Colin and Tin have laid out in their handbook.
>
> Sumit
>
>
>
> On 13 April 2017 at 19:59, Colin Watson <colin.watson at owasp.org <https://lists.owasp.org/mailman/listinfo/owasp-topten>> wrote:
>
> >* Thank you to everyone in the Top Ten project for all the effort in
> *>* creating this RC.
> *>>* Last year when the data call was announced, we had some discussion on the
> *>* Leaders' List about "lack of anti-automation":
> *>>* http://lists.owasp.org/pipermail/owasp-leaders/2016-June/016877.html <http://lists.owasp.org/pipermail/owasp-leaders/2016-June/016877.html>
> *>>* As pointed out to me in that discussion, "lack of anti-automation" was
> *>* included in the the 2013 Top 10 "Additional Risks to Consider":
> *>>* https://www.owasp.org/index.php/Top_10_2013-Details_About_Risk_Factors <https://www.owasp.org/index.php/Top_10_2013-Details_About_Risk_Factors>
> *>>* This item has been dropped from the 2017 RC1 completely - it is not in the
> *>* top 10 or in the additional risks. And none of the other 2013 risks include
> *>* these types of attack.
> *>>* I wonder if it is somehow meant to be included in A7 - the Automated
> *>* Threats Project is mentioned as a reference for A7. However, I feel this
> *>* may be incorrect since none of the threats in the scope of the Automated
> *>* Threats project appear to be mentioned in the description, explanation or
> *>* example attack scenarios for A7 in 2017 RC1. A7 seems to relate to
> *>* exploitation of vulnerabilities.
> *>>* Our project's unwanted automated usage are not about exploitation of
> *>* vulnerabilities, but instead often relate to misuse of inherent valid
> *>* functionality. To that end I feel it odd that such automated threats appear
> *>* neither in the 2017 RC1 Top 10, nor in the “additional risks to consider”.
> *>>* Whilst breach reporting does not provide comprehensive or representative
> *>* coverage of attacks, the following recent major incidents indicate the
> *>* types of issue:
> *>>>* Tesco Bank account enumeration (40,000 accounts)
> *>* http://www.coventrytelegraph.net/news/coventry-news/tesco- <http://www.coventrytelegraph.net/news/coventry-news/tesco->
> *>* bank-fraud-what-you-12138631
> *>>* Credential stuffing attacks on other sites following LinkedIn and Yahoo
> *>* breaches
> *>* https://medium.com/@UnifyID/credential-stuffing-how-prc- <https://medium.com/@UnifyID/credential-stuffing-how-prc->
> *>* almost-hacked-my-steam-2106a2f443e7
> *>>>* Some developers and testers ignore or do not think about such threats, and
> *>* therefore there is under reporting of these issues in many organisation’s
> *>* pen test reports and issue logging, yet lead to significant ongoing pain to
> *>* application owners/operators. I have never found any web application that
> *>* isn't at risk from some automated threat (we have listed 20 types of
> *>* threats, soon to be 21). The ease of exploitation is typically EASY
> *>* (because the functionality is inherently built into the web application).
> *>* Since automated threats can be a risk for many different types of
> *>* functionality, my belief is the prevalence is just as common as XSS, so
> *>* prevalence is WIDESPREAD and detectability is EASY. If exploited the impact
> *>* is typically MODERATE, often affecting the application’s owner, and users
> *>* and other parties.
> *>>* Regarding protections, in our project's Automated Threat Handbook we
> *>* document 14 classes of countermeasures for automated threats – only a
> *>* couple of which might be provided by something such as a WAF. Most
> *>* countermeasure classes are actually much more relevant to development
> *>* processes. Most do not appear in the "how do I prevent this" for A7, or any
> *>* other risk, in 2017 RC1.
> *>>* Colin Watson
> *>* Project co-leader
> *>* OWASP Automated Threats to Web Applications Project
> *>>* https://www.owasp.org/index.php/OWASP_Automated_Threats <https://www.owasp.org/index.php/OWASP_Automated_Threats>_
> *>* to_Web_Applications
> *>
>
>
>
> --
> Sumit Agarwal
> Member of Technical Staff
>
> _______________________________________________
> 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/20170428/6c9ca10d/attachment.html>


More information about the Owasp-topten mailing list