[Owasp-board] OWASP Top 10 2007 draft

Jeff Williams jeff.williams at owasp.org
Fri Nov 17 20:06:40 UTC 2006


Hi,

 

Dave and I argued about this for a while this AM and came up with this.

 


T10 2003

T10 2004

T10 2007 (Andrew Revised)

T10 2007 (Dave and Jeff)


A1 Unvalidated Parameters 

A1 Unvalidated Input 

 

 


A2 Broken Access Control
(A9 Remote Administration Flaws) 

A2 Broken Access Control 

A4 Authorization - Privilege Escalation

A4 Failure to Restrict URL Access

A5 Insecure Direct Object References


A3 Broken Account and Session Management 

A3 Broken Authentication and Session Management 

A3 Insufficient Authentication

A3 Broken Authentication and Session Management 


A4 Cross Site Scripting (XSS) Flaws 

A4 Cross Site Scripting (XSS) Flaws 

A1 Cross Site Scripting (XSS)

A1 Cross Site Scripting (XSS) Flaws


A5 Buffer Overflows 

A5 Buffer Overflows 

 

 


A6 Command Injection Flaws 

A6 Injection Flaws 

A2 SQL Injection

A2 Injection Flaws


A7 Error Handling Problems 

A7 Improper Error Handling 

 

A9 Improper Error Handling


A8 Insecure Use of Cryptography 

A8 Insecure Storage

 

A8 Insecure Cryptographic Storage


N/A 

A9 Denial of Service 

 

 


A10 Web and Application Server Misconfiguration 

A10 Insecure Configuration Management 

 

 


 

 

A5 Remote File Include

A7 Insecure Remote File Include


 

 

A6 CSRF

A6 Cross Site Request Forgery (CSRF) Flaws


 

 

A7 Content Spoofing

 


 

 

A8 Abuse of Functionality

 


 

 

A9 Information Leakage

 


 

 

A10 Insecure Storage

 


 

 

 

A10 Insecure Communications

 

 

I want to make sure there's a good justification for each change that we're
making.  That will make this much less jarring to the organizations who are
already using the T10.

 

I also think our ordering should combine some indication of IMPACT to the
raw frequency data (poor man's LIKELIHOOD) that we get from Mitre.

 

 

ITEMS I DON'T LIKE.

 

*	Content Spoofing (aka phishing) is really important and I think we
should add a note to the end of the document explaining that it is an attack
that uses a number of different vulnerabilities (both social and technical).

 

*	Abuse of Functionality - this is sort of an access control problem
where people ARE authorized for a function, but it's more powerful than the
app owners intended. Where did this come from as I can't find it in the
Mitre list.

 

*	Information Leakage - This is mostly an access control problem and
partially an error handling problem (when errors leak information to
attackers). SEE BELOW

 

*	Insecure Storage - Most of this sounds like forced browsing access
control issues. I think we should keep this area as a cryptographic problem
area.

 

 

ITEMS I THINK WE SHOULD ADD (or keep)

 

*	Improper Error Handling - #6 in the Mitre list under infoleak (but
we can sneak in some good error handling guidance)

 

*	Insecure Cryptographic Storage - #10 (also #28) in the Mitre list
under crypt.  Also a nod to the PCI folks.

 

*	Insecure Communications - This should cover lack of SSL. This is the
peer of Insecure Cryptographic Storage.  

 

*	Failure to Restrict URL Access - this would cover applications that
rely on presentation-layer "access control" - i.e. only use the "lack of UI
controls" to prevent access.  The attack is forced browsing.  Mitre #13,
#18, #29 

 

*	Insecure Direct Object References - #4, #6, #11 - this covers the
data layer access control issues like file path manipulation (dot dot),
changing UIDs, anywhere the application exposes a direct reference to an
internal object.

 

About access control (the last two items).  There seems to be some
disagreement as to whether we should break this category into several items
or not.  After thinking about it, I think it's a really good idea to split
the category.  But If we do break it down, let's try to split it nicely in
half.  What do you think of the proposed names above.

 

 

ITEMS ON THE BUBBLE.

 

*	Insecure Configuration Management - #16, #26, and #32 in the Mitre
list - This isn't a developer issue, but is obviously pretty important.
Some aspects of this can be distributed into the proper area - like
configuring web.xml can go into Failure to Restrict URL Access.

 

*	AppDOS - There's a good case for keeping this since it's Mitre #15,
but I'm fine with dropping it.

 

 

 

--Jeff

 

 

 

----------------------------------------------------

 

>From Andrew yesterday evening.

 

 

Dave asked me to fill in some definitions for each heading.

 

> 1. XSS

 

Obvious as it's easy to find and lays the ground work for CSRF.

 

> 2. SQL Injection

 

Should we include more injections, or leave just as SQL?

 

> 3. Insufficient Authentication

 

Brute forcing, etc. As per Top 10 2004 essentially.

 

> 4. Authorization - Privilege Escalation

 

Calling privileged functions, lack of authZ, etc. Same as Top 10 2004. Might
add some Ajax to this as I see this a lot in Ajax enabled apps

 

> 5. Remote File Include

 

Not just a PHP problem. Also for XML files, DTDs, etc.

 

> 6. CSRF

 

Should be in there

 

> 7. Content Spoofing

 

Phishing etc. Where attackers try to emulate your web site, or send better
looking e-mails than you do. Lots of loss via this mechanism.

 

> 8. Abuse of Functionality

 

Things like form mail and so on and send e-mail to member as found and used
by spam gangs to send e-mail from legitimate sites. AuthZ issues are above

 

> 9. Information Leakage

 

Include configuration files being able to be read, and misusing the
application to see other's records through tampering of the application
(Almost an authZ issue.)

 

> 10. Insecure Storage

 

Should include items such as pulling up report files for others if you know
how the naming scheme works, Ajax local storage mechanisms, and sites which
include protected items like Access databases - or worse - in the web root.

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-board/attachments/20061117/1983fe3b/attachment-0002.html>


More information about the Owasp-board mailing list