Following up on Dennis's mail last night I want to propose we change the
"Categories of Attacks" to "Classes of Vulnerabilities". Dennis summed up
some of the reasons why really well but I just want to expand and also touch
upon the intended scope of this project.

Let me explain "Classes of Vulnerabilities" (for people who know Object
Orientation this will be easy and make sense !)

A "Class of Vulnerabilities" is a group of vulnerabilities that share the
same basic behavior. An example is input validation. Input validation
vulnerabilities occur when the input is not expected and the system is not
able to deal with that input or behaves in an undesirable way.

Each "Class of Vulnerabilities" has instances. Instances of the "Input
Validation Class" would include OS Command Injection, SQl Injection,
Unicode Input, URL Encoded Input etc

Another example would be the parameter tampering class. Instances would
include hidden form field manipulation, cookie manipulation and URL query
string manipulation.

One main advantage of taking this approach is that it naturally ties back to
writing a much more structured methodology document which was the intent of
describing these issues. By Categorizing say an "Input Validation Class" we
will be able to spend cycles on discussing how you would go about testing
input validation, what tools could be used etc. Later in this project we can
then set about the important work of building a reference implementation of
an input filter that will prevent all of these issues.

As Dennis pointed out cataloging attacks is futile. Just look at the
variations on Unicode exploits there are or more importantly could be.

My personal feelings are also that whilst splitting issues into server-side
and client-side is useful it is not that effective. In the latest list I
saw, I noticed OS injection was a client-side issue. Surely its a
server-side issue for instance, its allowing poor input to enter the server
application. We all know that doing client-side validation securely is very
very difficult. Another thing to bear in mind when doing the list is that
the technology landscape is changing and we should make sure these classes
are generic enough to take that into account. I am thinking of projects like
those at IBM and mobile commerce where they are looking at doing secure
client-side processing. maybe we could label each class as being
server-side, client-side or both ?

Secondly Scope : There has been some debate about what should and shouldn't
be included. There is not doubt that systems can be subverted via social
engineering and via say infrastructure like DNS. The project was setup to
look at web application security. We should be referencing related things
but not re-hashing old ground. We do not want to compete with CVE. A class
of vulnerabilities is likely to be misconfigurations. At that stage we
should link to CVE's database for all the instances of those
misconfigurations but not be the record of source.

Another reason is that so far all of the classes are mainly focused on
black-box testing from the Internet. There are really effective ways of
testing source code for overflows, input ranges etc and we should be able to
reflect this.

I will re-order things into classes today if people think its a good idea ?

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