[Owasp-topten] 'A7 Insufficient Attack Protection' and conflicts of interest

Osama Elnaggar oelnaggar04 at gmail.com
Tue Apr 25 22:19:20 UTC 2017


Hi James,

I won't go into conjectures on whether or not vendors are affecting the Top
10 or other OWASP projects.  I appreciate the effort that Dave and other
OWASP project leaders and contributors put in to the various OWASP projects
and base my feedback on the validity or invalidity of the actual content.

However, I would agree with you that a greater emphasis be placed on trying
to build in as much of this into the application as possible while relying
on WAFs, RASP, etc. as an additional layer or if you can't patch your
applications quickly enough once a vulnerability is discovered.

As for the point related to WAFs, RASP and other third party tools limiting
penetration testers / bug bounty hunters, I think that this can easily be
resolved by either whitelisting the IPs used for the engagement for the
duration of the test (penetration testers) or bug bounty platforms
providing their researchers with access to an intermediary server which
they first connect to when testing the application (so the target would
just have to whitelist the corresponding intermediary server's IP).  So I
think this point is resolvable and would provide enterprises with the
additional security that these technologies can provide while not limiting
penetration testers and bug bounty hunters from finding valid security
concerns in the application).

I think the intent of A7 is that web applications are constantly under
attack and that developers and operations teams should take this into
consideration and do something to address this risk.  According to WhiteHat
Security (Slide 13 -
https://www.blackhat.com/docs/us-16/materials/us-16-Grossman-An-Insiders-Guide-To-Cyber-Insurance-And-Security-Guarantees.pdf),
it typically takes over 130 days for known vulnerabilities to be patched /
fixed.  No one would argue that web applications are notoriously poor at
providing visibility into what attacks are being carried out and fixing
them in an acceptable time frame.  You have insufficient security logging,
almost non-existent logging of suspicious or malicious activity, no defined
logging format, no integration with centralizing log management / SIEM,
etc. and very poor patch management of the core application and 3rd party
components.

Personally, I think that A7 just needs to be re-worded and I think split up
into:

* as a developer, how are you going to detect and log attacks?
* as a developer, how are you going to protect against detected attacks?
* as a developer, how are you going to enable quick patching when either
your application is vulnerable or the 3rd party libraries you use are?

For the first, a developer could take the initiative to log all sensitive
actions in the application + anything that violates the security policy
defined when they tackled the other OWASP Top 10 areas.  They can then
decide to output this in JSON so they can be easily consumed by logging
solutions within the environment and to feed their SOC teams with the
necessarily visibility.

Tackling protection is more difficult for a developer but there are
libraries that developers can use to help protect against brute forcing.
These won't protect against all attacks but can at least protect against
things such as password brute-force attacks quite easily.  At the very
least, the developer can ensure that these will be detected and that they
are providing their security operations teams with the necessary logs to
detect these attacks.

The last one is probably the most difficult for a developer to tackle as
this is border-line outside the scope of the developer.  But then again,
the "Security Misconfiguration" and "Using Components with Known
Vulnerabilities" are also borderline outside the scope of the developer. A
developer may launch their application with components that are up-to-date
and don't have know vulnerabilities but this isn't going to last for long.
So this last point is basically saying: bugs will be found on your site.
How quickly will you patch them (either permanently in the code if the
vulnerability is in your code and not a 3rd party component or virtually
using a WAF, RASP, etc. until it can be fixed and a new deployment rolled
out)?  Having this issue on the table and addressed by developers, project
managers, operations, etc is an important step forward instead of it not
even being a point of discussion as is currently the norm.  Security
vulnerabilities can be given greater weight and teams can try to streamline
the process for developing, testing, and rolling out patches.  WAFs and
RASP can add an additional layer of security until these issues are patched
in the code.  Not having something like this is the reason that we see 100+
days of exposures for known web applications as highlighted in the
presentation above and from practical experience.

Thanks.

-- 
Osama Elnaggar

On April 26, 2017 at 6:53:38 AM, Rory McCune (rory.mccune at owasp.org) wrote:

Hi James,

On this point

>> Layered security, defense in depth, anti-automation are all concepts
that prevent them from finding highly critical vulnerabilities quickly.
>You'll never see me objecting to defence in depth via actual exploit
mitigations like CSP, browser XSS filters, SRI, etc. That's because unlike
WAFs, they make the vulnerability harder to exploit rather >than making it
harder to find. In fact, perhaps Poor Defence in Depth would make a good
replacement for A7 if you're determined to have something that isn't a
standalone risk.

I think that this is the key point around where people, rightly, have a
problem with the idea of an OWASP Top 10 item mandating WAFs.  Like you I
test through WAFs some times and they're generally just an annoyance which
take up time in a time-limited review.

However I think there's a big difference between promoting add-on
mechanisms for attack response and having applications themselves respond
to attacks (as exemplified by projects like OWASP AppSensor).  As I
commented on your blog post, I think that active defence for web
applications is a good idea and one that tragically few applications
actually implement.

Would you think that if A7 were more clearly to be targeted at in-built
Application self-defence (and not add-on mechanisms like WAFs) that it
would make a better addition to the top 10?

Cheers

Rory


On Tue, Apr 25, 2017 at 6:45 PM, James Kettle <albinowax at gmail.com> wrote:

> Hi Christian,
>
> Thanks for raising these points. I agree that my post is cynical and if it
> wasn't for my prior experience with Contrast and OWASP Benchmark I'd have
> kept quiet. I actually wrote the Benchmark half of that blog post ages ago,
> but left it unpublished because Benchmark is relatively inconsequential and
> throwing around accusations isn't something I'm keen to make a habit of.
> The top 10 is far from inconsequential, so I felt that this time around it
> was necessary to publish.
>
> > I do not care of some adhoc poll dubs me belonging into a minority.
> Good to hear, me neither. The poll is just there to prevent people
> claiming I'm a crazy outlier and the only one who thinks this way.
>
> > I am sure Anti-CSRF tokens make it a lot harder for pentesters to report
> CSRF vulnerabilities.
> I don't think you've fully understood Eduardo's comment. CSRF tokens don't
> make it harder to find the vulnerability, they remove the vulnerability.
> This is a huge and extremely important difference.
>
> > you want easy access to the vulnerabilities and you do not mind leaving
> the door open for the bad guys as well.
> As every pentester who has encountered a WAF knows, all WAFs tend to do is
> slow down the process of finding and exploiting vulnerabilities. For a site
> that's being audited via a pentest or bug bounty hunters, this leads to
> vulnerabilities being missed and remaining unfixed. I should probably
> restate that I'm not against WAFs/RASP in general, it's just that they have
> significant disadvantages in some use cases which makes them stand out from
> other recommendation in the top 10.
>
> > Layered security, defense in depth, anti-automation are all concepts
> that prevent them from finding highly critical vulnerabilities quickly.
> You'll never see me objecting to defence in depth via actual exploit
> mitigations like CSP, browser XSS filters, SRI, etc. That's because unlike
> WAFs, they make the vulnerability harder to exploit rather than making it
> harder to find. In fact, perhaps Poor Defence in Depth would make a good
> replacement for A7 if you're determined to have something that isn't a
> standalone risk.
>
> Cheers,
>
> James
>
> On Tue, Apr 25, 2017 at 11:13 AM, Christian Folini <
> christian.folini at netnea.com> wrote:
>
>> James,
>>
>> On Tue, Apr 25, 2017 at 10:36:01AM +0100, James Kettle wrote:
>> > I've written up the rather depressing conclusion I came to regarding the
>> > introduction of A7 'Insufficient Attack Protection' over at
>> > http://www.skeletonscribe.net/2017/04/abusing-owasp.html
>>
>> I've read your post last night and I share your impression that the
>> conclusion is rather depressing. I also find your argumentation
>> rather depressing.
>>
>> > I'd particularly like to draw attention to Eduardo's insightful comment:
>> >
>> > Here is the net negative from "automatic protection" or pretty much just
>> > > any WAF. They make finding the vulnerabilities harder for the good
>> guys.
>>
>> Yes, protection generally prevents the good guys from finding
>> vulnerabilities. I am sure Anti-CSRF tokens make it a lot harder
>> for pentesters to report CSRF vulnerabilities. White-Hat hackers
>> market themselves as the guys that look at security with the
>> eyes of an attacker. Yet you want easy access to the vulnerabilities
>> and you do not mind leaving the door open for the bad guys as well.
>>
>> I read this clearly as an argument of an industry that defends its
>> business case. You then continue to accuse OWASP TopTen / Contrast /
>> Aspect and ultimately Dave himself (without naming him) of pushing
>> a different agenda. The jump from "do not make the life of pentesters
>> more difficult" to "Let's not allow solution providers have a stake in
>> this" has an almost cynical feel to it for me.
>>
>> When I woke up today, I returned to your article and got the idea that
>> white-hackers seem to have a business interest in imperfect security
>> solutions. Layered security, defense in depth, anti-automation are all
>> concepts that prevent them from finding highly critical vulnerabilities
>> quickly.
>>
>> From a defender's perspective, these are proven concepts that are
>> underrepresented in Top10 so far. That's why I think A7 is a welcome
>> addition.
>>
>> And I do not care of some adhoc poll dubs me belonging into a minority.
>> New ideas are not accepted by a majority from the start. They take
>> time to develop. I am confident this will happen here as well.
>>
>> Regards,
>>
>> Christian Folini
>>
>> --
>> There has grown in the minds of certain groups in this country the
>> idea that just because a man or corporation has made a profit out of the
>> public for a number of years, the government and the courts are charged
>> with guaranteeing such a profit in the future, even in the face of
>> changing circumstances and contrary to public interest. This strange
>> doctrine is supported by neither statute or common law. Neither
>> corporations or individuals have the right to come into court and ask
>> that the clock of history be stopped, or turned back.
>> --- Robert Heinlein, Life-Line, 1939
>>
>
>
> _______________________________________________
> Owasp-topten mailing list
> Owasp-topten at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-topten
>
>
_______________________________________________
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/20170425/94b22f10/attachment-0001.html>


More information about the Owasp-topten mailing list