[Owasp-topten] Some more thoughts on A7

Delbrouck-Konetzko Thorsten thorsten.delbrouck at gi-de.com
Tue Apr 18 16:09:12 UTC 2017

(x-posting from the ISF forum)

From an infosec management / infosec design perspective you can fine-tune (the usually central) reactive components, you can even opt to not implement any automated reactive behavior and only get alerts to follow-up manually etc. (see the old “IDS vs IPS” discussion).
I'm not saying the risk described in A7 doesn't exist (it does!) but the other nine aspects are passive or "self-containing" in a way that if every supplier of every IT components implements those nine there's a good chance you end up with a somewhat robust but still working or at the very least manageable (or "debug-able") environment.

A7 has the potential to change that due to the reactive nature. Website not responding? Could be the CMS attack protection that was triggered. Could also be the database attack protection that was triggered. Or the webserver attack protection that was triggered. Or that one plugin’s attack protection that was triggered.  You get the idea (and that’s not even mentioning the DoS potential of automated responses).
This takes us from "build robust, reliable and predictable applications which play nice together" to "... and add some random active behavior".

Today I have a paragraph like “Externally developed services must at the very minimum make sure to mitigate the OWASP Top 10 Most Critical Web Application Security Risks.” added to all relevant IT RFPs as a ‘catch all’ (and ‘just in case’).

With the current RC1 wording I’d have to explicitly exclude A7 which diminishes the value of “The Top 10”.


Thorsten Delbrouck
Corporate Chief Information Security Officer

Phone +49 89 4119-3895  |  Fax +49 89 4119-1840  |  Mobile +49 172 301 344 5  |  mailto:thorsten.delbrouck at gi-de.com
Giesecke & Devrient GmbH  |  Prinzregentenstr. 159, D-81677 Munich, Germany  |  https://www.gi-de.com/

From: owasp-topten-bounces+thorsten.delbrouck=gi-de.com at lists.owasp.org [mailto:owasp-topten-bounces+thorsten.delbrouck=gi-de.com at lists.owasp.org] On Behalf Of Rory McCune
Sent: Samstag, 15. April 2017 21:50
To: OWASP TopTen <owasp-topten at lists.owasp.org>
Subject: [Owasp-topten] Some more thoughts on A7

Hi all,
As this one seems to be generating the most interest, I thought I'd add in some more thoughts to the pile for consideration  :)

The title of this one is “Insufficient Attack Protection” and at core I think its about applications actively protecting themselves from attack, which I think is a great idea.

What I don’t think it’s about, and it might benefit from some clarifications in this regard, is a requirement for all applications to use a WAF or RASP.

So why do I like this idea? Well if you think about almost every application kind of has some attack protection already, with account lockout policies. The application sees something which isn’t right, a login with the wrong password, and after a pre-determined number of incorrect attempts, it takes an action, perhaps locking the account, perhaps asking for additional details, perhaps alerting an administrator (maybe even all three!).

So the concept in general is already in use, but I think a lot of applications would benefit from extending it. For example if a user says that their first name is <script>alert(1)</script> that’s almost definitely not true! It’s a pretty clear indication that someone is trying to attack your application and you can make that attackers life harder by restricting their access or taking some other action, depending on the context.

Another one could be if there’s a dropdown in your application with 5 possible values and the form is submitted with something that’s not in that list. An ordinary user pretty much won’t ever do this, so it’s an indication that someone is either editing the HTML before submission, or using a proxy to intercept and modify the request, both reasonable indications (in most cases) that something untoward is happening.

These are pretty simplistic examples but luckily OWASP Appsensor exists to provide more details.

This kind of action can make automated attacks much harder to execute and also can provide excellent alerting for blue teams to work with, and I think that’s a big win. One key aspect of this is that the detection and response is embedded into the application. One problem with external add-ons is that they can lack context about what is and is not expected behaviour in an application, that kind of context only really exists within the application itself.

Predictably and quite justifiably there have been a lot of concerns and questions raised about this suggested change.

·         This will make Pentesters and Bug Bounty People’s lives harder . Yep that one’s true, but then as pentesters and bug bounty researchers are pseudo bad guys, isn’t that really a good thing? Flippancy aside, I think that applications with a lot of active defence need to have test environments where this is disabled specifically to allow for automated testing. Some testing would occur there, and then when the final product is ready to be tested, you can enable the protections and check that they’re working ok.

·         This is a mandate for WAF vendors I really hope not. Sure some applications won’t be able to retro-fit controls, and might want to use a WAF. But two things on that, one there are open source WAFs available and two, when the security industry started pushing 2FA harder, I don’t recall anyone saying that “hey this is just a vendor pitch for RSA tokens” and if they had, I wouldn’t have agreed with them either :)

·         There’s no statistical evidence that this is a problem . I’m a bit torn on this one. On the one hand that’s likely true and data based approaches are good. On the other hand, how would you measure this? No automated scanning tool is going to put “hey we didn’t get kicked out whilst testing” in their report is it? I can only offer anecdotal evidence, that I only very very rarely see any kind of application active protection in play, so it’s definitely not commonly deployed.

·         This isn’t a vulnerability . Yep that’s true, but AFAICS this is a list of risks, not a list of vulnerabilities. It may get used as a list of vulnerabilities, but on the title page it says risks :)



Vorsitzender des Aufsichtsrats: Prof. Klaus Josef Lutz
Geschäftsführer: Ralf Wintergerst (Vorsitzender, CEO), Hans Wolfgang Kunz, Dr. Peter Zattler (CFO)
Gesellschaftssitz: München, Handelsregister Amtsgericht München HRB 4619
Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser E-Mail erforderlich ist. G&D engagiert sich für den Klimaschutz.<http://www.gi-de.com/deu/de/about_g_d/responsibility_2/climate_environmental_protection/climate-and-environmental-protection.jsp>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170418/06c80137/attachment-0001.html>

More information about the Owasp-topten mailing list