[Owasp-topten] Some more thoughts on A7
rory.mccune at owasp.org
Wed Apr 19 11:40:14 UTC 2017
Interesting points. I think that the challenge here is in defining the
"purpose" of the OWASP Top 10. It is used in a variety of ways, but I'm
not sure that it should be constrained to fit a specific use case.
For example some tools companies use/used it by saying that they "address
the OWASP Top 10", does that mean that it should be constrained to only
items that can be covered by those tools? I'd argue it shouldn't be. With
2013's introduction of A9 Using Components with Known Vulnerabilities, that
ruled out most/all black box tools from being able to cover the Top 10, but
that doesn't, to me, make that an incorrect decision.
In terms of unintend consequences, sure a badly implemented control can
cause problems, that doesn't mean that you shouldn't specify the control,
but that you should take care in implementing it. I've seen instances of
SQL Injection protection blocking input with ' characters when it
shouldn't, does that mean we shouldn't have SQL Injection in the Top 10?
For me the Top 10 is best served in attempting to improve web application
security by suggesting what the current largest areas of risk/weakness are,
and not worry too much about applicability. The reason being that there are
many places where the Top 10 is referenced, and if it tries to constrain
itself to fit them all, it's likely to be an ineffectual standard.
On Tue, Apr 18, 2017 at 5:09 PM, Delbrouck-Konetzko Thorsten <
thorsten.delbrouck at gi-de.com> wrote:
> *(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 <+49%2089%2041193895> | Fax +49 89 4119-1840
> <+49%2089%2041191840> | Mobile +49 172 301 344 5 <+49%20172%203013445>
> | mailto:thorsten.delbrouck at gi-de.com <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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-topten