[Owasp-leaders] [Owasp-topten] OWASP Top 10 Methodology

Tom Brennan tomb at owasp.org
Thu Mar 14 22:04:29 UTC 2013


OWASP has a testing tool https://www.owasp.org/index.php/OWASP_HTTP_Post_Tool

It is (testing for the risk) also described in the owasp testing guide...


On Mar 14, 2013, at 4:54 PM, Eoin <eoin.keary at owasp.org> wrote:

> LOIC is app level Ddos. Was very popular with Anon :)
> 
> Eoin Keary
> Owasp Global Board
> +353 87 977 2988
> 
> 
> On 14 Mar 2013, at 16:41, "Dave Wichers" <dave.wichers at owasp.org> wrote:
> 
>> I definitely agree that there are things that APPS can do to help prevent app level DOS attacks.
>>  
>> But here’s the issue.  The OWASP Top 10 is about the current biggest risks. And I suspect, but don’t know for sure, that most real world DOS attacks against apps are actually against the apps infrastructure, not the app itself. We need to look into the details of whatever metrics we have access to, to see if that is true.
>>  
>> So, if the real world attacks are against the infrastructure, then if we add DOS to the Top 10, we should talk about infrastructure defenses, since that’s what is really happening.  We don’t want to add DOS to the Top 10 because its common, and then present a bunch of app level defenses that don’t actually stop the kinds of attacks that are actually occurring.
>>  
>> And adding a bunch of network level defenses against DOS to the OWASP Top 10 feels a little weird. And to others, NOT having DOS in the Top 10 feels a little weird too.
>>  
>> As I said, this is a tricky issue for the Top 10.
>>  
>> -Dave
>>  
>> From: Rory McCune [mailto:rory.mccune at owasp.org] 
>> Sent: Thursday, March 14, 2013 12:36 PM
>> To: Dave Wichers
>> Cc: Ryan Barnett; OWASP Leaders; OWASP TopTen
>> Subject: Re: [Owasp-topten] [Owasp-leaders] OWASP Top 10 Methodology
>>  
>> Hi, 
>>  
>> I think that there are some things that app. developers /owners could do to address app DoS (although as you say I think that network DDoS is more common).
>>  
>> The kind of App DoS I'm thinking of would be where a simple GET or POST request could trigger a computationally expensive transaction on the application database or server. So for example something like a large database query that's triggered by a product search.  Presumably the application has been tested for standard usage patterns but may not have been tested for someone making very large numbers of searches quickly.
>>  
>> In terms of mitigation, I'd say that there would be a two phase approach.  First would be identification of what transactions/requests caused large processing loads and secondly would be implementing some form of protection, which could take the form of basic rate limiting for a given transaction or perhaps at a more advanced level detecting an unusual usage pattern (i.e. ordinary users browse from the login page through to the search page and then search once, whereas these IPs are hitting the search page repeatedly without any other page visit) and then blocking/limiting those IPs in relation to those transactions.
>>  
>> The advantage of defending this at the application layer is that there's likely to be more visibility/understanding of what constitutes unusual behavior and also what the high processing requirement transactions are.
>>  
>> Cheers
>>  
>> Rory
>>  
>> 
>> On Thu, Mar 14, 2013 at 4:26 PM, Dave Wichers <dave.wichers at owasp.org> wrote:
>> Hey everyone. Related to DDOS, (Today’s latest event is: http://www.bankinfosecurity.com/ddos-6-banks-hit-on-same-day-a-5607), do we have any stats/metrics on how many DDOS attacks are at the application level vs. the network level?
>>  
>> The OWASP Top 10 is about Web Apps, not network security. And I know if they DDOS the server and take out the app, then it’s an app problem, but is there anything the APP itself can do about the most common DDOS attacks?
>>  
>> I’m trying to figure out, if we added DDOS to the Top 10, what advice we could provide to developers/app owners on how to mitigate this risk? And if all the advice is at the network level, because that’s the best / easiest place to defend against this, does that belong in a top 10 list for apps? Maybe/Maybe not.
>>  
>> I’m trying to encourage discussion here. I’m not saying I don’t think it belongs in the Top 10. This is tricky/complex issue worth discussing.
>>  
>> -Dave
>>  
>>  
>> From: Ryan Barnett [mailto:ryan.barnett at owasp.org] 
>> Sent: Wednesday, March 13, 2013 11:00 AM
>> To: Dave Wichers
>> Cc: Michael Coates; OWASP Leaders; OWASP TopTen
>> 
>> Subject: Re: [Owasp-leaders] OWASP Top 10 Methodology
>>  
>> FYI - I have added links to sample attack reports to this page -
>> https://www.owasp.org/index.php/Top_10_2013/ProjectMethodology#Suggested_Enhancements
>>  
>> -Ryan
>>  
>> On Tue, Mar 5, 2013 at 9:33 AM, Dave Wichers <dave.wichers at owasp.org> wrote:
>> Thanks Ryan for taking the lead on this step of the methodology. I’m very interested in seeing what the various attack metric sources we can get our hands on say about the prevalence of different kinds of attacks.
>>  
>> One comment about the prevalence factor in the Top 10 is that its definition is:
>>  
>> The likelihood that an attacker would successfully attack the application given this vulnerability.  I could imagine some attack metrics only measure attempts to attack (like random DOSing, or random attempts at SQL injection/XSS) but don’t or can’t measure the number of actually successful attacks.
>>  
>> And I think the likelihood of success is pretty important. Take Reflected XSS for example. It’s pretty prevalent, it’s pretty easy to find, but it can be hard to successfully pull off.
>>  
>> Don’t get me wrong, I think knowing what attack attempts are actually occurring out there in the wild is great information to know. But I’m not sure if that data is an exact match to what we consider the likelihood of actual successful attack in the Top 10 as its defined today.
>>  
>> -Dave
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20130314/1d56e2af/attachment-0001.html>


More information about the OWASP-Leaders mailing list