RE: Top Ten Web App Sec Problems

["Steven M. Christey" <coley () linus mitre org>]

I'm going to answer multiple questions in the same email.

There have been some inquiries about vulnerability statistics.  I
posted some overall statistics to Bugtraq last week, in a post titled
"On vulnerabilities in open and closed source products"

  http://msgs.securepoint.com/cgi-bin/get/bugtraq0211/303.html

A more extensive study is at:

  http://cve.mitre.org/board/archives/2002-10/msg00005.html

Several people have noted poor encryption as a major concern.  It's #8
on the CVE overall top ten.


Richard M. Smith asked:

> Are there any known examples of cross-site scripting bugs being
> exploited?

Some public examples have already been mentioned.  Some of the
well-publicized e-commerce or e-banking hacks may have been performed
through XSS; however, there is so little detail about such hacks that
one cannot know for sure.

XSS can have further-reaching implications than "just" cookie theft,
although that seems to be the focus.  For example, the ability to
inject HTML into a web page would allow someone to exploit
vulnerabilities in web clients.  See some of the discussions in the
November Bugtraq thread "A technique to mitigate cookie-stealing XSS
attacks"


Jeff Williams said:

> Another issue in putting together a "top ten" list is the "superclass"
> issue you raised. Some of these problems are categories, others are
> very specific instances of a vulnerability. I think we should try to
> list vulnerabilities that are "just right" ;-)  We should try to
> minimize overlap between vulnerabilities, yet draw a big enough
> circle that a reasonable class of problems is represented

Agreed, but this is the difficult part :-) For example,
canonicalization and directory traversal are very closely linked, yet
they are discrete entities - you can have one without the other.  I
suspect that the OWASP "attack components" have analogs in the
vulnerability world.  The most obvious example is the symlink
vulnerability, which has components including (a) bad permissions, (b)
easily predictable filenames, and (c) race conditions enabled through
non-atomic operations.  Take any one of these components away, and you
no longer have a symlink vulnerability.  In the web app world, say you
have a password file under the document root; you may have a mixture
of (a) poor/no encryption, (b) bad permissions or ACLs, and possibly
(c) poor design.  Even buffer overflows have a number of variants
besides "start copying bytes at offset 0 and run past the end of the
buffer."

There's also a close relationship between the vulnerability (the
programmer/designer's "mistake") and the attack, but these lines often
get blurry, especially in terminology.  E.g. if you view "directory
traversal" as "any means of escaping a restricted directory by
manipulating pathnames," then you'll say that exploits involving
"/absolute/path/here" or "C:\drive" are directory traversal, whereas
others may only view ".." and its variants as directory traversal (I
personally view these as "sufficiently different" - fixing/preventing
one does not necessarily fix the other).

I've been playing around with lower-level categorizations but have not
made a lot of concrete progress, as it is a low-priority task.

> A final factor that should go into the "top ten" decision process is
> the overall risk represented by a vulnerability. How easy is the hole
> to discover?

This has varying answers, even for the same type of issue.  For
example, format string vulnerabilities are easily findable in open
source but more difficult in closed source.

> Are there existing tools to search for it?

... both in source code auditing and testing ...

> Do you need special tools to exploit? What are the consequences of
> exploiting the hole?

One can only provide an estimate for the likely results of an exploit
against a vulnerability.  Directory traversal severities can vary
anywhere from directory listings to arbitrary command execution.

> Our choices should represent the ones that we think will be the most
> serious for industry during the next year or so.

XSS is one type of vulnerability whose severity is variable and not
fully understood, IMO.

It sounds like you're advocating a "top ten" that's based on other
criteria besides "the most frequently occurring" types of issues.  The
basic question is, what would be the proper criteria for such a top
ten list, and what would be the goals?

- Steve