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

Sumit Agarwal sumit at shapesecurity.com
Wed Apr 26 00:20:18 UTC 2017


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.


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
*>>* 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
*>>* 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-
*>* bank-fraud-what-you-12138631
*>>* Credential stuffing attacks on other sites following LinkedIn and Yahoo
*>* breaches
*>* 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
*>* to_Web_Applications

Sumit Agarwal
Member of Technical Staff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170425/629f61f3/attachment.html>

More information about the Owasp-topten mailing list