[Owasp-topten] Some more thoughts on A7

Dave Wichers dave.wichers at owasp.org
Wed Apr 19 14:36:59 UTC 2017


Rory/Thorsten,

Thanks for your input. Rory - if you can suggest specific clarifications or
changes to A7, that would be most helpful.

Thorsten, any user of the T10 can choose to address or not address any of
the risks it described. We do understand that A7 is different in that most
apps don't do this today, and that's actually the problem we are trying to
raise awareness of. If you choose to tell your vendors to meet everything
except A7 in the next Top 10, that's totally fine. But as an awareness
document, we feel this is an important risk to raise awareness of, which is
why we proposed it as an addition to the T10.

I've also just recently replied to a different thread on this list with
some background on how the T10 gets updated, and specifically why we felt
adding A7 and A10 was important.  That might provide additional useful
background for you.

-Dave

p.s. Sorry everyone for the radio silence from me for the past 4-5 days. I
had a busy long Easter weekend with 15 people in my house and 25 people for
dinner and I'm just now digging out from that.

On Wed, Apr 19, 2017 at 7:40 AM, Rory McCune <rory.mccune at owasp.org> wrote:

> Hi,
>
> 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.
>
> Kind Regards
>
> Rory McCune
>
> 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”.
>>
>>
>>
>> Best
>>
>> Thorsten
>>
>>
>>
>>
>>
>> *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
>> 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
>>
>>
>> *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>
>>
>
>
> _______________________________________________
> 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/20170419/655363ca/attachment-0001.html>


More information about the Owasp-topten mailing list