Fwd: [Owasp-topten] Maybe the top ten doesn't need (much) revising....

[Chuck]

Andre sent this to the list, but it got bounced.  I'll give it a try.

Chuck

---------- Forwarded message ----------
From: Ludwig, Andre <ludwiga at fortrex.com>
Date: Oct 7, 2005 2:09 PM
Subject: RE: [Owasp-topten] Maybe the top ten doesn't need (much) revising....
To: Chuck <chuck.lists at gmail.com>, owasp-topten at lists.sourceforge.net


All,

I agree with Chuck on the value of an "audit list" that contained
standard vulnerabilities or controls that could be put in place.  I feel
that with the adoption of the OWASP T10 into PCI-DSS and other standards
has over extended the purpose of the T10.  With that being said I do
feel that we should produce a version of the T10 that fits the need of
these organizations.  Such a list should include a list of controls that
should be in place (proper input/output validation, proper session
management, proper crypto, etc).  While this list may be as simple as
check boxes there should be a reference to some material that presents
an example and explanation of the control and its goals (OWASP Web App
Guide).  I think the creation of such an Audit list would release the
T10 from some of the places it has been stuck (PCI-DSS) and possibly
misused.

Maybe we can call it The OWASP Web Application Auditing Standard aka
TOWAAS (or toe-waaz).


That being said I do feel that we could change the current Top Ten to
better raise awareness for new and emerging threats.  The addition of a
new bullet point for "phishing" and possibly "pharming" based attacks I
feel would bring the T10 to where it should be.  I think by merging
input validation with SQL injection we could kill two birds with one
stone (possibly giving a brief blurb on the relation). I feel strongly
that the T10 should remain a list of the Top Ten current threat vectors
faced by web applications; this should include the supporting
infrastructure of an application (DNS, Web servers, Databases, etc) and
not just the code being used.   The Top Ten should serve as the means
for generating awareness in the community for the noted vectors of
attack (propaganda/cheerleading).  Anything more raising awareness
should be viewed as misuse of the intentions of the list.  It is this
misuse that should demonstrate that there is a very valid need for such
an auditing checklist, and with that I think we should move forward with
producing such a list for adoption by various organizations.

And for the record I do realize that both pharming and phising attacks
don't have to even touch an application, but they do directly effect the
organizations that utilize web applications.  And it is with that in
mind that I feel the need to incorporate these vectors of attack into
the Top Ten, as the purpose is to raise awareness for attack vectors.


So the way I see the Top Ten is as follows...


A1

Unvalidated Input / Parameter Injection

Information from web requests is not validated before being used by a
web application. Attackers can use these flaws to attack backend
components through a web application such as databases, web services,
and file systems.  Typical attacks include SQL Injection, system command
injection, and server side includes (SSI) injection.

A2

Broken Access Control

Restrictions on what authenticated users are allowed to do are not
properly enforced. Attackers can exploit these flaws to access other
users' accounts, view sensitive files, or use unauthorized functions.
A3

Broken Authentication and Session Management

Account credentials and session tokens are not properly protected.
Attackers that can compromise passwords, keys, session cookies, or other
tokens can defeat authentication restrictions and assume other users'
identities.

A4

Cross Site Scripting (XSS) Flaws

The web application can be used as a mechanism to transport an attack to
an end user's browser. A successful attack can disclose the end user's
session token, control the user's browser, attack the users local
machine, or spoof content to fool the user.

A5

Buffer Overflows

Web application components in some languages that do not properly
validate input can be crashed and, in some cases, used to take control
of a process. These components can include CGI, libraries, drivers, and
web application server components.

A6

Application Misrepresentation

The manipulation of user browsers or DNS servers may allow an attacker
to misrepresent a legitimate application. This effectively redirects
traffic and information from legitimate sites to malicious sites that
can compromise user login credentials and data.  These types of attacks
include Phishing and Pharming based attacks.

A7

Improper Error Handling

Error conditions that occur during normal operation are not handled
properly. If an attacker can cause errors to occur that the web
application does not handle, they can gain detailed system information,
deny service, cause security mechanisms to fail, or crash the server.

A8

Insecure Storage

Web applications frequently use cryptographic functions to protect
information and credentials. These functions and the code to integrate
them have proven difficult to code properly, frequently resulting in
weak protection.

A9

Denial of Service

Attackers can consume web application resources to a point where other
legitimate users can no longer access or use the application. Attackers
can also lock users out of their accounts or even cause the entire
application to fail.

A10

Insecure Configuration Management

Having a strong server configuration standard is critical to a secure
web application. These servers have many configuration options that
affect security and are not secure out of the box.



Please note that I made changes to the XSS entry as well as the Input
validation and of course added the Application Misrepresentation entry.


Thoughts? Comments? Flames?


Andre Ludwig, CISSP