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:]
Sent: Thursday, October 23, 2003 10:44 AM
To: 'Mark Curphey';
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
