[Owasp-topten] Some more thoughts on A7

Rory McCune rory.mccune at owasp.org
Sat Apr 15 19:49:42 UTC 2017


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 :)

Cheers

Rory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-topten/attachments/20170415/72588d78/attachment.html>


More information about the Owasp-topten mailing list