RE: [was] Meeting Minutes

was message

Subject: RE: [was] Meeting Minutes

From: "Mark Curphey" <mark@curphey.com>

To: "'Srinivas Mantripragada'" <srinivas@netcontinuum.com>,"'Dawes, Rogan \(ZA - Johannesburg\)'" <rdawes@deloitte.co.za>,<was@lists.oasis-open.org>

Date: Wed, 5 Nov 2003 19:52:52 -0500

Thanks Shrinivas. I will get this all taken care of when I get back from vacation. See next mail.

Do you think we should have a separate <protection> element where we define a protection signature that will peer with (and in some cases be the same as) the <test> element ? There are a few open source protection tools that are interested in consuming WAS and if the sig format can be used in that context as well, i.e. easier to share between the two technologies I think that's a great benefit.

From: Srinivas Mantripragada [mailto:srinivas@netcontinuum.com]
Sent: Thursday, October 30, 2003 9:31 PM
To: Mark Curphey; 'Dawes, Rogan (ZA - Johannesburg)'; was@lists.oasis-open.org

I do like the way the top-level blocks are currently laid out.

Meta-Data
Profile
Test

Couple of comments:

- probably need to have a root element. Does this provide classification for a single vulnerability or a class of vulnerabilties with common
attributes?
- revisioning history support.
- backward URI reference links to CVE, CERT ..
- xsd supports standard datatypes, xsd:date, xsd:anyURI, xsd:NCName, xsd:QName, xsd:normalizedString, so we could just use them.
- risk ranking type should have a globally unique namespace, e.g. urn:oasis:names:tc:was:riskRanking:...

I do feel that representing dynamic tests are important. Probably these can be addressed post 1.0. From a firewall perspective, the test
portion needs to contain enough specificity of where the attack signature lies, i.e. header, query, content, session etc. The attack signature
also needs to be fairly generically repesented, i.e. regex form for optimal condensation of rules. The AVDL has precise description
support for this.

I do feel that classification and defense should be cleanly decoupled from one another with cross-referencability to each another.

thx,

-Srinivas

--

Srinivas Mantripragada, Ph.D
Architect
NetContinuum
1705 Wyatt Drive
Santa Clara, CA 95053
Off Ph: 408-961-5644
Fax: 408-986-8997
srinivas@netcontinuum.com
http://www.netcontinuum.com

Mark Curphey wrote:

Thanks Srinivas,

As an application firewall vendor what data do you need to be passed to build a signature ? My suspicions are it it different from the test case ?

I am starting to think that maybe there are a few sections needed, each of which contain similar data but are optimized at specific things.

So far we have defined the three core sections of

Meta-Data

Profile

Test

Maybe we should have

Meta-Data - Which I think anyone needs for management

Profile - in which many elements would be optional if the Test is Dynamic but mandatory if the Test was Static

Test - on Static for known issues and one Dynamic for "Dynamic" issues.

Defense - - Maybe as simple as a RAW section

Test could actually be the generic Test that we have now that I think will be pretty competent for the static issues and a Dynamic test that maybe refined for the dynamic tests as described by the conversation Rogan and I had. Dynamic tests would be very much more conditional etc. They are (?) probably not in scope from WAS 1.0.

Either way I wondering if the approach / flow should be that upon conditional success of a Test, to then write out the Defense data ?

From: Srinivas Mantripragada [mailto:srinivas@netcontinuum.com]
Sent: Thursday, October 30, 2003 2:00 AM
To: Mark Curphey; 'Dawes, Rogan (ZA - Johannesburg)'

The expressibility of dynamic issues is definitely important in my opinion. Most of the interesting vulnerabilities known today are
through second (or multiple) order descends. The problem quickly gets nasty though when the payload characteristics need to
be determined through a descend of if- conditions not necessarly all transceding through the same protocol. It gets really
complex and necessitates a complete language support. Why not just provide a <raw> ... </raw> container to describe the
whole test description sequence(s), e.g perl syntax?

thx,

-Srinivas

--

Srinivas Mantripragada, Ph.D
Architect
NetContinuum
1705 Wyatt Drive
Santa Clara, CA 95053
Off Ph: 408-961-5644
Fax: 408-986-8997
srinivas@netcontinuum.com
http://www.netcontinuum.com

Mark Curphey wrote:

I guess its just me and you Rogan ;-)

Maybe we should think about this in terms of two things and set the scope of
WAS 1.0 to deal with the simpler problem for now.

If you conceptually define issues as "Static" and "Dynamic" then the static
problem space is much easier. I think it is also true to say that the WAS
charter was to deal with Static issues and not dynamic. 

A "static" issue is a pre-defined, repeatable issue such as those reported
on bugtraq. A "Dynamic" or general issue would be those generic issues such
as SQL injection as you describe. 

I think it would be really interesting to look at tests like the one you
describe below but personally think its out of scope for WAS 1.0. Do you
agree ?

How about for WAS 2.0 ? We could have a staticTest and a dynamicTest ;-)


-----Original Message-----
From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes@deloitte.co.za] 
Sent: Thursday, October 23, 2003 10:44 AM
To: 'Mark Curphey'; was@lists.oasis-open.org

First, some definitions:

Analyser: The part of the program that looks at an URL, or parses the HTML,
and identifies the fact that we should test for XSS or SQL injection here.
Engine: The part of the program that, given an URL, and a WAS test, actually
constructs TCP connections to the server under test, and iterates through
the WAS steps to determine success and failure of the test.

My thoughts on this have been basically that the analyser could construct a
dynamic test for a particular variable at a particular URL, based on a
vendor-proprietary list of SQL injection strings, and error messages that
could result. Very roughly, and not well-formed at all:

<TEST>
<Variable name="sqlstring">
  <value>string1</value>
  <value>string2</value>
</variable>
<step>
  <request>
 
<URI>http://www.server.com/cgi/app.cgi?var1=${sqlstring}&var2=whatever</URI>
  </request>
  <Response>
    <SetVariable name="odbcerror">.*odbc error.*</SetVariable>
  </Response>
  <TestCriteria>
    <Variable name="odbcerror" type="equals"></Variable>
  </TestCriteria>
</TEST>

This test would iterate through the list of SQL injection strings provided,
testing the parameter "var1" for injection vulnerabilities.

Then a similar test could be constructed for var2, etc

The TestResult message would indicate which variable was being tested, so
that it could be reported on.

The interesting thing to note is that it is trivial to include
"pre-requisite" steps to login, get an authenticated cookie, etc if this is
a requirement for the test. It would just be a case of assisting the
operator to create those steps, possibly based on a pre-existing sequence of
conversations observed via a proxy plugin, for example.

The same could be done for XSS, or any other input validation tests that
need to be done.

Rogan

P.S. I'm not actually suggesting that WAS-XML is the right format to
describe these tests internally to the application. I'm sure that there
would be much more efficient representations possible. But the analyser
*could* use WAS-XML to hand the tests off to one or more "child executor"s
on different machines, possibly in different geographical locations, to
spread the load, and also test for any IP specific controls built in to the
web application.

I kind of envision something like:

WAS[] tests = generateSQLTests(request, prerequisiteSteps) // tests.length
== the number of parameters found in "request"

Result[] results = engine.executeTests(tests); // results.length <=
tests.length * sqlstrings.length // depending on whether we report
successful AND unsuccessful tests

-----Original Message-----
From: Mark Curphey [mailto:mark@curphey.com]
Sent: 23 October 2003 04:11 PM
To: 'Dawes, Rogan (ZA - Johannesburg)'; was@lists.oasis-open.org
Subject: RE: [was] Meeting Minutes

Rogan / Team,

One thing I have been thinking about is possibly a different approach 
to dealing with the problem (or maybe the same depending on your view 
point).

I think I would be right in saying that today we try to describe a 
complete transaction. In a simple case like a XSS that would be the 
http request being sent along with any pre and post conditions.

Another approach or more accurately a powerful extension maybe to 
extrapolate the attack in such a way that the scenario could become;

Get a URI, operate on response. So in the case of a xss test you could 
request a URI, parse the http headers or html and then build test 
requests with a defined payload.

Essentially this approach (extension) would mean you could potentially 
create generic XSS, path traversal tests etc which then takes WAS to a 
powerful dynamic testing language from a static description format.

Any thoughts on this approach?

-----Original Message-----
From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes@deloitte.co.za]
Sent: Thursday, October 23, 2003 1:28 AM
To: 'Mark Curphey '; 'was@lists.oasis-open.org '

Hi folks,

The WAS engine is checked into the CVS for WebScarab at SourceForge, 
or you can get an interim release from my personal web page at 
http://home.intekom.co.za/rdawes/WebScarab.jar

The WAS engine is not accessible through the GUI. You will need to 
call it in the following way:

java -cp webscarab.jar org.owasp.webscarab.plugin.was.WASExecutor url 
testfile

You may also need to get the jakarta commons libs, if it complains 
about missing class files.

Currently, it does nothing with the test description. In particular, 
it does not check to see whether it applies to a particular URL. That 
will probably be done this week some time.

Also, it does not implement Request Body functionality, so you cannot 
do POST. I have also not yet implemented building a request query from 
individual parameter elements. If you want an URL with parameters, 
build it in the <URL> block using ${variable} if necessary.

Currently, I think it should be sufficient to implement most of the 
Whisker and Nikto tests, given the restrictions above.

I hope to have time to work on it this week.

Rogan

-----Original Message-----
From: Mark Curphey
To: was@lists.oasis-open.org
Sent: 10/22/03 9:42 PM
Subject: [was] Meeting Minutes

Meeting minutes from last weeks meeting are now posted on the OASIS 
site.

In short Rogan Dawes has created a basic WAS execution engine in order 
for the TC members to explore the limitations of the existing VulnXML 
format and design WAS accordingly.

So at this point we need people to start creating test cases, 
recording real limitations and designing WAS 1.0 accordingly.

Please take time to download the current engine, build test cases and 
share your experience.

Rogan, can you update everyone with the limitations of the current 
engine build so we don't build test cases that are currently not 
implemented in the reference engine, and point everyone to the latest 
build ?

Thanks

To unsubscribe from this mailing list (and be removed from the roster 
of the OASIS TC), go to 
http://www.oasis-open.org/apps/org/workgroup/was/members/leave
_workgroup
.php.

Important Notice: This email is subject to important restrictions, 
qualifications and disclaimers ("the Disclaimer") that must be 
accessed and read by clicking here or by copying and pasting the 
following address into your Internet browser's address bar:
http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form 
part of the content of this email in terms of Section 11 of the 
Electronic Communications and Transactions Act, 25 of 2002. If you 
cannot access the Disclaimer, please obtain a copy thereof from us by 
sending an email to ClientServiceCentre@Deloitte.co.za.

To unsubscribe from this mailing list (and be removed from the roster 
of the OASIS TC), go to 
http://www.oasis-open.org/apps/org/workgroup/was/members/leave
_workgroup.php
.

To unsubscribe from this mailing list (and be removed from the roster 
of the OASIS TC), go to 
http://www.oasis-open.org/apps/org/workgroup/was/members/leave

_workgroup.php.

Important Notice: This email is subject to important restrictions,
qualifications and disclaimers ("the Disclaimer") that must be accessed and
read by clicking here or by copying and pasting the following address into
your Internet browser's address bar: http://www.Deloitte.co.za/Disc.htm. The
Disclaimer is deemed to form part of the content of this email in terms of
Section 11 of the Electronic Communications and Transactions Act, 25 of
2002. If you cannot access the Disclaimer, please obtain a copy thereof from
us by sending an email to ClientServiceCentre@Deloitte.co.za.

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup.php
.



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup.php.