[Owasp-topten] OWASP Top Ten Possible Changes (long)

[Chuck]

Hi again, responses below....

On 7/27/05, Achim Hoffmann <kirke11 at securenet.de> wrote:
> !! I think we should either eliminate A4, A5, and A6
> !! I prefer to eliminate A4-A6 to make room for more vulnerabilities.
> 
> I agree that A4 and A5 are identical if A5 is only meant for missuse with
> for example Session Riding. Otherwise "Insecure Forms" are subject to
> "Data Validation" (see more details below).

Actually, my comment there was about the A4-A6 in the current top ten.
 What I was saying is that XSS, buffer overflows, and injection flaws
are sub-types of input validation flaws.  I agree with you that this
should be generalized to "Data Validation", to cover input and output.
 You could even make it "Data Validation and Coding" because sometimes
encoding / decoding of data is an alternative to validating it, such
as in XSS.

And, I think that what I called "Insecure Forms" (resistance to CSRF,
I am open to changing the name) is different from Data Validation.  I
think of Data Validation as regular expression checks on input.  A
CSRF will pass the regular expression tests, so there is more to
preventing this.  You need to have some sort of state on the server
that you can match up with the client who is submitting the form.

Maybe instead of "Insecure Forms", we could name this one something
like "Trusting the Client" to include CSRF protections, but also other
things like trusting the client not to alter hidden form fields,
cookies, and referrer headers.
 
> !! If there is another issue that people would like to add, you could
> !! combine A6 and A7 to make room for something else.
> 
> IMHO A6 and A7 are very similar and a more common used term is "Information
> Disclosure". How about renaming it to that? Means
>   A6 Information Disclosure (including data disclosure, error handling)
> Keep in mind that some things interfere with A10.

I agree with that A6 and A7 could be combined, but then I would have a
"Top Nine" list :-)

> As said above, I tend to distinguish Access Control and Session Management.

I think that Session Management, Authentication, and Access Control
are all different enough to warrant separate entries.  You could think
of it as a three phase process....

Authentication is ensuring people are who they say they are.  In
practice, it covers how passwords are validated, password reset,
multi-factor authentication if used, single sign on if used,
resistance to brute force, etc.

Session Management is (basically) ensuring that once a user is
authenticated, an attacker cannot assume that user's identity to the
application.

Access Control is ensuring that the user (who is authenticated and not
changed) only accesses the right data.  It is harder to generalize
since it is application specific, but basically comes down to roles,
permissions, etc.

I think this is a useful discussion, hopefully some others will join
in.  I think a lot of people are at Black Hat now, so maybe next week.
 I'll be away from email until next Wednesday, too, for DefCon, so
I'll join back in then.

Have a good weekend, all.

Chuck