No subject
Wed Nov 1 13:37:27 EST 2006
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.
The names and descriptions above do not articulate all the issues that =
these
vulnerabilities are supposed to contain. Difference between A2 and A3 =
is
not clear. From reading the web pages describing these issues, these =
two
are meant to cover this list, which to me seems like a bit of a jumble:
A2:
- Non-users accessing parts of application meant for users only
- Users accessing parts of application they should not be able to (such =
as
administrative pages)
- Users accessing parts of application as another user (without changing =
the
session id)
- Caching of pages (in client browser)
- Directory traversal attacks
- File permissions
A3:
- Attacker using a user's session ID to access application as that user =
(may
have been sniffed, guessed, shoulder surfed, pulled off user's computer,
etc).
- Attacker forcing user to use a given session ID (Session fixation)
- Attacker getting user's userid and password (may have been sniffed,
guessed, shoulder surfed, pulled off user's computer, etc).
- Password change / reset / complexity
- Brute force
Possible Solution:
Three parts:
1. Directory traversal should belong in A10, it is a web server
configuration issue 2. File permission issues could be moved into new =
"Data
disclosure"
vulnerability (see below)
3. Split Authentication from A3 into a new vulnerability ("Broken
Authentication") to cover
- Attacker getting user's userid and password (may have been sniffed,
guessed, shoulder surfed, pulled off user's computer, etc).
- Insecure password change / reset process: attacker can change or reset =
a
user's password
- Brute force: an attacker can quickly guess a user's password
Issue: some vulnerabilities are not mentioned
Possible new items:
- Insecure Forms: vulnerable to Cross Site Request Forgeries (aka =
Session
Riding), attacker can get a user to submit a form on the application =
from
another site (phishing)
- Trust of data from client: application trusts data from the client =
such as
cookie values, hidden form fields, referrer headers, etc. May also =
cover
client side Javascript input validation. This may be included in A1, =
but I
didn't see it specifically mentioned.
- Data disclosure: application discloses internal workings or source =
code in
html comments or backup, old, or extra files on the web server. This =
whole
issue could maybe be combined with A7. The backup, etc files issue =
could be
included in A10 or A2. This would also include things like "Google
Hacking".
"Meta" Vulnerabilities : I think that these are important issues, but =
they
are at a higher level than the rest of these issues so I don't know that
they fit with the rest of the top ten list.
- Insecure Web Services: web application may have a lot of security
planning, but web services may not get the same scrutiny. Basically, =
web
services should have the top ten applied to them as well.
- Insecure Life Cycle: The web application may be secure when initially
fielded, but updates to the application are not sufficiently tested for
security and new vulnerabilities appear
- Reliance on external mechanisms: If the web application has flaws and =
is
protected by an external mechanism (such as a web application
firewall) it may be possible to send data to the application that will =
pass
the external mechanism's checks, but still exploit the application. An
example of this would be HTTP Request Smuggling.=20
Basically, the application itself should be secured rather than relying =
on
an external mechanism. External mechanisms may still be valuable as
"defence in depth", but they are not a substitute for a secure =
application.
In short, here is my proposed new "Top Ten"
A1 Unvalidated Input (includes XSS, injection, buffer overflows, and =
trust
of data from client)
A2 Broken Access Control
A3 Broken Authentication
A4 Broken Session Management
A5 Insecure Forms
A6 Internal Data Disclosure
A7 Improper Error Handling
A8 Insecure Storage
A9 Denial of Service
A10 Insecure Configuration Management
If there is another issue that people would like to add, you could =
combine
A6 and A7 to make room for something else.
What do you all think? If OWASP is going to update the Top Ten, it =
might be
good to do it before the OWASP conference in October so the changes =
could be
announced, or maybe the powers that be could get together to discus the
changes at the conference.
That's all, have a good one, everybody.
Chuck Willis
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies =
from
IBM. Find simple to follow Roadmaps, straightforward articles, =
informative
Webcasts and more! Get everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Owasp-topten mailing list
Owasp-topten at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-topten
More information about the Owasp-washington
mailing list