[Owasp-topten] An alternate view of "Risks"
dave.wichers at aspectsecurity.com
Sat Dec 5 10:05:24 EST 2009
Sorry for the very LONG delay in replying. Been a bit busy... Here goes.
Jeff and I debated for a while about providing more precision along
exactly the same lines. For example, I think we came up with something
like: A1: Server side interpreter injection, which is essentially what
But, we finally decided on two things:
1) Using existing terminology is really important as people are familiar
2) Brevity (within reason) is also important.
So, by adding lots of words to make the categories more precise, I think
we'd end up doing more harm than good. For example, saying Execution of
malicious script through web pages, may be more precise, but no one
would be familiar with this term, and would have to read our definition
of what it means, and then most people would mentally translate this to
'Oh, they mean XSS'. So, we think sticking with the familiar term is for
more valuable than any extra precision we might gain.
Again, the Top 10 is primarily an awareness document, so simplicity is
probably far more important than precision (in my opinion).
Each area is defined in the Top 10 so people can read what we 'mean' by
each title. If you think the definitions are confusing, that would also
be great feedback and we could work on improving and providing better
So, I read each title you proposed and certainly some of the are more
precise, but none of them grabbed me that they would be 'better', which
I know is vague and very subject to personal opinion. If you have
specific favorites you want to champion, feel free and I'd be happy to
From: owasp-topten-bounces at lists.owasp.org
[mailto:owasp-topten-bounces at lists.owasp.org] On Behalf Of
robert at webappsec.org
Sent: Monday, November 23, 2009 2:17 PM
To: Steven M. Christey
Cc: owasp-topten at lists.owasp.org
Subject: Re: [Owasp-topten] An alternate view of "Risks"
> I've been thinking on what Robert said about trying to be better about
> terminology, and while I originally thought that I understood "risk"
> the context of early drafts of the Top Ten, now I'm not so sure. At
> very least, the T10 still has the problem of using
> terminology in the names. There's a challenge of using commonly-known
> terminology so you don't leave your core audience in the dark, and I'm
> definitely an advocate for using established terminology where
> Perhaps one way of addressing this would be to change the current
> and maybe make another minor tweak here and there into something that
> think of as "risk," which is going to smell a lot like "attack" to
> people, "threat" to others, and maybe there's some notion of
> impact," too.
> A1 - Injection
> could be renamed to:
> Modification of queries or commands to the back-end interpreter
> This is not necessarily "attack" the way I think of it - this doesn't
> into any specifics about the method/procedure/technique that the
> uses to accomplish the goal.
> A programmer or development manager seeing this new name might react
> the following fashion: "wait, attackers can modify my queries?
> big concern." That speaks more directly to people than "Injection."
> A2 - XSS
> Consider: Execution of malicious script through web pages
> A3 - broken authC / session mgt
> Consider: Compromise of users' identities or sessions
> A4 - Insecure Direct Object Reference
> Consider: Unprotected Access to Internal Objects or Resources
> [I don't particularly like this suggestion]
> A5 - CSRF
> Consider: Unintentional Requests Being Sent from Legitimate Users
> A6 - Security Misconfiguration
> might not need a name change
> A7 - Failure to Restrict URL Access
> Consider: Exposure of Restricted Functionality through URLs
> A8 - Unvalidated Redirects and Forwards
> Consider: Redirection to Unexpected or Malicious Web Sites
> A9 - Insecure Cryptographic Storage
> Consider: Theft or undetectable corruption of stored data
> A10 - Insufficient Transport Layer Protection
> Consider: Theft of data or user information during transmission
> Hope somebody understands what I'm trying to get at, I'm having some
> difficulty trying to explain it. It's different but I'm not fully
> it's any better.
While I may not entirely agree with the particular renaming suggestions,
I do agree with your conclusion for the context
of risks. While your email may be considered a wrench throw into the
gears of the top ten, I think this is a good opportunity
to clarify scope/terminology to assist this document with its maturity.
The Top 10 is utilized in PCI (as Dave points out
), and given its importance/impact to an organizations
requirements, should have as clear of a message as possible to remove
ambiguity not only in its logic, but by its consumers as well.
I've noticed that neither of our threads have received a single reply,
would be great to see what others on the list/working group
have to say that may fill in some of the
gaps/misconceptions/conversations we may have missed.
- Robert A.
> - Steve
Owasp-topten mailing list
Owasp-topten at lists.owasp.org
More information about the Owasp-topten