I agree and the Application Misrepresentation bullet point could use
more work. It is just a question of generalizing the title then
inserting into the explanation a few pertinent examples to get the point
across. (I attempted to do this with the pharming and phishing example)
I suppose what you propose as table like format I was attempting to get
done with additional sentences. I think both approaches have their
pros and cons, possibly a combination of both would be in order? =20
I do like from a usability perspective the idea of have the top 10 in a
table like format.=20
I must raise the point that we may not want to be associated with the
continued cheerleading of buzzwords. I feel that it would be in the
best interests of everybody involved if we could tie those buzzwords to
the actual root causes of the vulnerabilities (Bo's =3D input =
XSS =3D Input validation, etc). While we should mention buzzwords (for
the PHB's) I think we should attempt to educate those who don't
understand the root cause of the issues they face. That for me is the
only way to truly attack the issue at hand. Ignorance
Just my two cents of course, and please do feel free to differ, point
fingers, flame, curse, or generally mock me. Makes for a more
interesting thread ;)=20
From: Ofer Shezaf [mailto:Ofer.Shezaf@...
Sent: Monday, October 10, 2005 5:33 PM
To: owasp-topten@...; Ludwig, Andre
Subject: RE: [Owasp-topten] Maybe the top ten doesn't need (much)
The OWASP top 10 list strength lies in the fact that it addresses the
concerns of the users, rather than being a structured compilation by
For example, from my "technical" point of view XSS and buffer overflow
are also unvalidated input issues, but for a customer they are very
different "buzzwords", and so is SQL injection. Another example is
"Application Misrepresentation", which took me a second to understand
and others may just skip. "Phishing" and "pharming" should be better
My suggestion is to acknowledge this duality and add to the top 10
"master table" a column, which might be called "popular exploitations",
and which would include the common "field" terminology for the problem.
You will also notice that this way we have much more room in the top 10.
So for example the following top 10 items will look like:
- Unvalidated Input
- SQL Injection, Cross Site Scripting, System Command injection, Buffer
- Broken Access Control
- Forceful browsing, Path Traversal
- Broken Authentication and Session Management
- Session Hijacking, Weak session IDs and password=20
- Application Misrepresentation
- Phishing, Pharming
CTO, Breach Security
Phone (US): +1 (760) 268.1924 ext. 702
Phone (Israel): +972 (9) 956.0036 ext.212
Cell: +972 (54) 443.1119
> -----Original Message-----
> From: owasp-topten-admin@... [mailto:owasp-topten-
> admin@...] On Behalf Of Ludwig, Andre
> Sent: Monday, October 10, 2005 4:14 PM
> To: owasp-topten@...
> Subject: FW: [Owasp-topten] Maybe the top ten doesn't need (much)
> Just wanted to ping back the group and see if anyone had any feedback
> the below ideas.
> Andre Ludwig
> -----Original Message-----
> Sent: Friday, October 07, 2005 2:17 PM
> To: 'Chuck'; owasp-topten@...
> Subject: RE: [Owasp-topten] Maybe the top ten doesn't need (much)
> I agree with Chuck on the value of an "audit list" that contained
> standard vulnerabilities or controls that could be put in place. I
> that with the adoption of the OWASP T10 into PCI-DSS and other
> 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
> 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
> 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
> new bullet point for "phishing" and possibly "pharming" based attacks
> 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
> faced by web applications; this should include the supporting
> infrastructure of an application (DNS, Web servers, Databases, etc)
> 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
> an auditing checklist, and with that I think we should move forward
> 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
> 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...
> 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
> injection, and server side includes (SSI) injection.
> 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.
> Broken Authentication and Session Management
> Account credentials and session tokens are not properly protected.
> Attackers that can compromise passwords, keys, session cookies, or
> tokens can defeat authentication restrictions and assume other users'
> Cross Site Scripting (XSS) Flaws
> The web application can be used as a mechanism to transport an attack
> 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.
> 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,
> web application server components.
> 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
> include Phishing and Pharming based attacks.
> 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
> deny service, cause security mechanisms to fail, or crash the server.
> 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.
> Denial of Service
> Attackers can consume web application resources to a point where other
> legitimate users can no longer access or use the application.
> can also lock users out of their accounts or even cause the entire
> application to fail.
> 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
> Thoughts? Comments? Flames?
> Andre Ludwig, CISSP
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> Owasp-topten mailing list