Re: OWASP Top Ten - My Case For Updating It

[Andrew van der Stock <vanderaj () greebo net>]

The SANS community is working on a revision to their old Top 20 list.  
I put forward a list, but it seems that they are going back to the  
Top 20 vulnerabilities of 2005, a reactive view that will not help  
security. Sure it will help in the short term, but it does not  
address why those Top 20 issues came to be.

The OWASP Top 10 needs to address preventative and structural  
measures to ensure that even if we don't know about (say) HTTP  
Request Smuggling (or name a new vulnerability type), the danger of  
the new threat is very low as organizations who've taken our  
suggestions on board have adequate precautions built-in.

I am very much against the idea that you patch crud. This only  
creates patched crud with a false sense of security, and leaves you  
open to the problem the next time some low-life scuzzbucket releases  
CrudAttack.B or CrudAttack.C ... or CrudAttack.BNM. We need less crud.

Andrew

On 10/07/2005, at 12:40 PM, Jeff Williams wrote:

> Absolutely.  It's high time that we put together a real standard  
> for web application security.  As Mark points out, the Top Ten  
> really doesn't serve purposes beyond awareness very well.  The  
> first thing is to identify a project leader and some key  
> contributors.  I hope that Mark will consider leading the effort.   
> I suggest we take the discussion to the owasp- 
> topten () lists sourceforge net mailing list.  You can sign up at  
> http://lists.sourceforge.net/lists/listinfo/owasp-topten.
>
> --Jeff
>
> ----- Original Message ----- From: "Mark Curphey" <mark () curphey com>
> To: <webappsec () securityfocus com>
> Cc: "'Jeff Williams'" <jeff.williams () owasp org>
> Sent: Saturday, July 09, 2005 4:42 PM
> Subject: OWASP Top Ten - My Case For Updating It
>
>
>
> > I think the OWASP Top Ten needs a serious re-think. Here is my  
> > simple case
> > for discussion / consideration.
> >
> > No one will dispute the fact that the Top Ten has been a  
> > phenomenal success.
> > It has raised awareness and brought web application security to  
> > the desks of
> > CIO's across the world. It has touched the payment card industry,  
> > Federal
> > Trade Commission and the US gov to name a few. But it has also  
> > been and is
> > continuing to be adopted (and abused) for purposes that were far  
> > beyond its
> > original intent. These uses and  misuse that are not "fit for  
> > purpose" are
> > in my opinion leading to a significant degree of FUD, false sense of
> > security and mis-information in the market. I therefore propose  
> > through this
> > mail a re-write to ensure that the OWASP Top Ten is an effective  
> > and useful
> > standard.
> >
> > I break this proposal down into a discussion of the;
> >
> > current format of the top ten
> > current uses of the top ten
> > issues as the result of the format and uses of the top ten
> > proposal for improvement
> >
> > Current format of the top ten
> >
> > Todays OWASP Top 10 consists of;
> >
> > Unvalidated Input
> > Broken Access Control
> > Broken Authentication and Session Management
> > Cross Site Scripting (XSS) Flaws
> > Buffer Overflows
> > Injection Flaws
> > Improper Error Handling
> > Insecure Storage
> > Denial of Service
> > Insecure Configuration Management
> >
> > If you examine the overall picture you will see that the list is  
> > actually a
> > mix of 1, Security Mechanisms, 2, Attack Patterns and 3,  
> > Vulnerabilities.
> >
> > Security Mechanisms
> > -Broken Access Control
> > -Broken Authentication and Session Management
> > -Insecure Configuration Management
> > -Improper Error Handling
> > -Insecure Storage
> >
> > Attack Patterns
> > -Injection Flaws
> > -Denial of Service
> >
> > Vulnerabilities
> > -Cross Site Scripting (XSS) Flaws
> > -Buffer Overflows
> >
> > Current Uses of the Top Ten
> > As well as awareness, the popularity of the OWASP Top Ten has lead  
> > to people
> > adopting it as a;
> >
> > -Criteria for evaluating technology (web app scanners, firewalls)
> > -Metrics and comparison for software security programs
> > -Education outline
> > -Assessment framework
> >
> > Issues as the result of the format and uses of the top ten
> > The OWASP Top ten is an awareness document but in my humble  
> > opinion not
> > suitable for any of the current uses for the top ten listed above.  
> > As we
> > have already seen by the FUD from many vendors especially web  
> > application
> > firewall vendors, to say you protect from broken authentication is a
> > meaningless statement. To say you find broken authorization issues  
> > is also a
> > meaningless statement from an assessment vendor. As formal evaluation
> > criteria has long known you have to define a protection or assessment
> > profile. The OWASP Top Ten is not a protection or an assessment  
> > profile. A
> > vendor could accurately say that they find Insecure storage if  
> > they parsed
> > data stream and found a clear-text account value in a cookie  
> > header. However
> > they would have likely missed a web application whose developer  
> > used a
> > predictable random seed for a low key length symmetric cipher.  
> > This leads to
> > a significant sense of false security and hyped marketing FUD.
> >
> > In order to develop any useable metrics or comparison programs you  
> > must be
> > comparing apples to apples and oranges to oranges. If you mix attack
> > patterns, security mechanisms and attacks you can not.
> >
> > While teaching developers about a small pragmatic list of issues  
> > is clearly
> > a good thing, many companies are missing big issues by focusing on  
> > a subset
> > of the symptoms of software security and the not the causes. In  
> > order to
> > provide pragmatic and effective education you have to teach  
> > developers how
> > to address the root causes of issues to prevent them from re- 
> > occurring.
> >
> > Many companies are looking to test sites against the top ten. I  
> > recently
> > looked at a site that passed the OWASP Top Ten but was 100% open  
> > to an
> > adversary to completely take it over. While statements explain  
> > that this is
> > not a complete list are in place, without a testing criteria  
> > uneducated or
> > novice companies will use the Top Ten as a testing yard stick. The  
> > PCI
> > adoption is a dangerous issue that demonstrates this point. When  
> > MasterCard
> > were hacked the first thing the company did was to say they passed  
> > the PCI
> > tests. This will be the case with the OWASP Top Ten.
> >
> > If the problem of web application security is poor software  
> > quality, it is a
> > natural conclusion that the solution is to build better software.  
> > Not once
> > in the top ten does the list address the fact that the majority of  
> > software
> > is built without a design, security requirements or a repeatable  
> > software
> > security development process.
> >
> > Proposal for improvement
> >
> > Create a set of T10's that are fit for purpose;
> >
> > T10 - Attack Patterns
> > T10 - Common Vulnerabilities
> > T10 - Root Causes of Insecure Web Applications
> > T10 - Things a company should have as part of its software  
> > security program
> > T10 - Things to look for in a protection system
> > T10 - Things to look for in an assessment system
> >
> > The FUD in the application security marketing is continuing to  
> > increase at
> > an alarming rate and measures like this in my humble opinion are  
> > urgently
> > needed to recover some credibility and prevent a pandemic.
> >
> > Cheers,
> >
> >
> >
> > Mark