>> = Steve Christey
> = Jeff Williams

>> 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?
>
>The problem with "most frequently occurring" is that our instruments
>for measuring are so poor that I don't believe they represent reality.

Agreed. There is a bias in what's publicly reported, too - reflected
by "fads" (why else is XSS so popular these days? oh yeah, it's really
easy to find) and the amount of efforts by researchers. There are too
many cases when a piece of software suffers the "death of a thousand
cuts" with advisory after advisory on variants of the same issue,
which often demonstrates how incomplete the original research was.

>The public vulnerability databases don't list problems with individual
>websites (although there's at least an argument that they should).

We've had to deal with this in CVE and, in short, stay away from it.
The general approach has been to record problems that require
"customer action."

>Companies don't release information about vulnerabilities in their
>sites, assuming that they even uncover them.

Maybe some bold company will do this one day, I hope... and while many
in the security community will sing their praises, their stock price
would probably plummet :-(

>I'd like to see a top ten list that helps to crystallize the issue for
>government and industry.

I'd like to see something that customers can use to tell their vendors
"we want you to guarantee that you won't make these mistakes."
Something that the security community can use to say "this is the same
old issue and vendors shouldn't be making such obvious mistakes."
That's a little pie-in-the-sky, but one benefit of the SANS Top Ten
was that it gave "management" a means of talking about vulnerabilities
in a non-technical fashion.

>Roughly how big do you think the risk from web application
>vulnerabilties is? Equal to the risk from "network" vulnerabilties
>like SANS lists? Half? Quarter?

That's a great question. In web apps, you have situations which the
risk to the end user is as important (or more so) than risk to the
server/provider, and the customer may have different priorities,
security-wise, than the server/provider.

I bet the "real" answer will change over the next few years, too.
Server software seems to be getting much more robust, at least from
major vendors. Major server software these days is hit by
"interesting" or new problems more often than not. As server software
is better protected, people may start looking at web apps more than
they already do.

>I think we should select the vulnerabilities that pose the greatest
>aggregate risk to government and industry (in terms of likelihood and
>impact).

Makes sense - and easier said than done :-)

Here's my cut, which is probably biased by the overall set of publicly
known vulnerabilities. One "pro" of this bias would be that it
captures errors made by programmers of widely varying skill levels
(instead of companies who hire consultants, who might be in better
shape overall). This may in some sense reflect the lowest hanging
fruit.

- Directory traversal

- XSS (for 3 reasons: it's commonplace, every single input is suspect,
  and educating programmers about XSS will have cascading effects)

- Shell metacharacters / OS system command injection

- Poor credential management (cookies, whatever)

- Unprotected privileged apps (i.e. bypassing the "login" screen and
  directly accessing a program that should require authentication, but
  assumes the login screen handled it)

- Parameter/form tampering

- Canonicalization (since it can defeat otherwise good input
  validation)

- SQL injection

- storing sensitive files under the web root

- plaintext passwords - in URLs or in data files

- bad crypto

- buffer overflows

OK, that's 12 ;-)

One thing that would be nice to see is a document that is organized
around overall application functionality, versus vulnerability type.
Many secure programming doc's are organized by vulnerability type
instead of, say, "managing files," "protecting data," "processing
incoming data," "using encryption," "performing authentication," etc.
Some bug types will cross many functional areas, but this sort of
organization might be more useful to programmers.

- Steve

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]