|
I think the dynamic tests are quite important for scaling. The search space
is far too big otherwise. Imagine a web application with 10 forms and 10
fields per form. Then let's say we want to test each for XSS (10 tests) and SQL
injection (10 tests). That's 1000 tests right there. At 2 seconds
per test, that's over 30 minutes. And that's just for a tiny site with a
tiny number of tiny forms and a small number of tests.
I think the idea about letting an operator set up a test is very
cool. You'd want to be able to define both negative (no the response
doesn't have match this regex) and positive criteria (yes the response matches
this regex). Anything else would indicate a problem.
----- Original Message -----
Sent: Wednesday, October 29, 2003 7:35
PM
Subject: RE: [was] Meeting Minutes
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.
|