At Mark Curphey's request, I'm posting this to the list.

It's really nice to see some work going on at this level of detail!

I haven't had the time to read the entire thread closely, so please
forgive me if you already heard of some of these recommendations.

First, the current list seems to mix attacks and vulnerabilities a
little bit, at least the way I view things. Take the obvious examples
of URL manipulation or hidden form field manipulation. Each of these
are components of an attack. But the underlying vulnerabilities that
are being exploited could include any of the input validation problems
such as buffer overflows or path traversals, for example.

Consider the less obvious example of session hijacking. The hijacking
itself requires a sequence of steps that take advantage of a
combination of several underlying problems:
  - traffic can be sniffed because it's in cleartext or lametext (my
    just-coined term for bad encryption :-)
  - original sequence numbers are easily guessed (due to factors such
    as: no randomization at all; a small space of possible values;
    and/or a bad selection of a random source, e.g. assuming that
    /dev/urandom exists on a system)

Maybe it's not essential for your purposes to try to make this
distinction, but IDSes will be looking at the attack, and programmers
should know how to avoid the vulnerability. Obviously, understanding
both aspects is important, so I'll move on now.

In the Informational class, consider separating *intentional*
information leaks versus *accidental* leaks. An application may, by
design, intentionally reveal sensitive information when a certain
error occurs. However, there can be cases in which a separate type of
vulnerability is exploited, which causes an inadvertent information
leak, such as a buffer overflow which can cause portions of memory
contents to be dumped. The way I see things, an accidental leak means
that there's really a different problem at play - the leak is the
*result* of exploitation of a problem, just like executing code can be
a result of a buffer overflow attack.

Other types of problems
-----------------------

- sensitive data or configuration being installed within the web
  document root

- server-side processing redirection. I have no idea what term to use
  for this, but basically: say you've got a web server module that
  does a fancy formatting for files of type "Z." If an attacker
  directly calls it with a file of type "X," whose contents aren't
  supposed to be seen directly (such as source code), then you've got
  a problem.

- similar to the previous: bad selection of a server-side processor
  based on unusual extensions. Examples: various Java servlet
  vulnerabilities have occurred because someone asked for a ".JsP"
  file instead of a ".JSP"

- 8.3 filenames

- DOS device names (aux, con, etc.)

- data and configuration file permissions (not always made insecure by
  default, and sometimes hard-coded). These types of problems are
  extremely common and often overlooked, maybe because they're not as
  cool as format string vulnerabilities and CSS ;-)

- direct access to administrator functionality without authentication.
  This falls under a few of your categories already (it deals with
  input validation as well as URL manipulation), but it's so common in
  CGI programs... Example: you've got a program that prompts for an
  administrator password, which is then used as a hidden form field to
  access administrator functionality. But the programmer assumes that
  the only way into that function is through the front "login page,"
  so the program doesn't double-check the admin password.

- no variable initialization. This is a problem in things like PHP,
  where variable names and values can be fed directly from the CGI
  request.

- bad encryption, or the lack of encryption of sensitive data. See
  most major incidents involving online credit card theft where the
  attacker just grabbed an unencrypted database of product orders.

- On the client side, you've got sandbox implementation errors
  (e.g. problems where the Java Virtual Machine runs code where it
  shouldn't), and similarly, mobile functions that are improperly
  marked as "safe" for execution (see various Internet Explorer
  problems for ActiveX controls)

- memory leaks. Other kinds of "resource leaks" can occur upon
  improper termination of a process/session.

- running scripts/servers at escalated privileges. Sometimes this is
  an insecure default setting, whereas other times the product design
  requires a dangerously high level of privileges.

Hope this helps some. I didn't mention local-only vulnerabilities
like symbolic link problems, as the current list seems to care about
network-based attacks, but of course some web-based programs can be
compromised even further if they also have local problems.

- Steve

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