Re: [was] WAS Test

[Rogan Dawes <rogan@dawes.za.net>]

There have not been any significant changes to the last published 
VulnXML schema, if that is what you are asking. At this point, I have 
been trying to get feedback from list members on a couple of proposals 
to extend the existing format to support concurrent access (via 
ThreadGroup and Thread constructs), as well as engine specific 404 
detection.

I have no idea what the sqlInjection complex type refers to. It 
definitely does NOT refer to either the original VulnXML, or the 
proposed updates.

Your analysis of the current state of Test is pretty accurate.

In order to move forward, the most important thing is that people 
RESPOND. I've made some suggestions, and had NO response, whether 
mailling folks directly, or via the list. I don't want to do this in a 
vacuum, and don't want to do it by myself.

I am happy that we move to using schemas to describe WAS-XML.

To reiterate past discussion, the weak areas currently under 
"discussion" are concurrency and 404 detection.

Concurrency is important to allow for tests that require two or more 
simultaneous requests to reveal a problem, such as failure to lock data 
structures (see the Webgoat simultaneous logon as an example).

My suggestion was to create a ThreadGroup element, which contains 2 or 
more Thread elements, followed by a Test element. Each Thread element 
would contain 1 or more Request-Response-Test elements.

By extending the spec to allow for specifying delays before each step is 
executed, we should be able to describe concurrent requests reasonably 
well. The Test after the Thread elements is intended to test the results 
of all previous threads together, once all have completed.

w.r.t 404 detection, I have come to the conclusion that it is better for 
the detection of custom 404 responses to be performed by the executing 
engine, then trying to code all the possibilities into the XML. Firstly, 
the XML would become out of date really quickly, and actually, I believe 
that it is impossible to describe all the ways in which web servers 
react to non-existent pages in such a format.

It makes sense that the executing engine could probe the server under 
test prior to the start, request e.g. an index page that DOES exist, 
request a couple of obviously bogus non-existent URLs, and determine how 
the particular server responds, and applies similar logic to pages 
retrieved later. It could be as simple as a "<Test URLExists="true">" or 
whatever. This would result in a callback to the engine which would 
perform some analysis on the Response that it got to the Request, react 
appropriately.

suggestions for appropriate attribute tags or tag names are appreciated ;-)

Regards,

Rogan








Mark Curphey wrote:

> Guys
> 
> Yuval Ben-Itzak (now an individual member) is going to help act as
> custodian to get the Test element complete. I have sent him the last few
> weeks emails as I fear they may not have got to him. He has this
> question that I thought I would forward.
> 
> <snip>
> Is Rogan's Schema to describe a vulnerability still valid ? or do we use
> another one.
> As I did not see a definition for the ComplexType element "sqlInjection"
> in the file you sent me I thought it probably reference Rogan's schema -
> am I correct ?
> </snip>
> 
> This is where I think the Test element development is.
> 
> Initial VulnXML DTD defined
> Some weaknesses identified and styles / approaches to moving forward
> (calling reusable functions etc)
> Initial Java execution engine built into WebScarab for POC
> Plans for a C# engine to show interoperability of signatures
> 
> Things that I know need to happen before WAS 1.0 spec release are;
> 
> Confirm, explore and document the weaknesses in VulnXML
> Convert that existing work to Schema and use schema moving forward
> Develop test cases to explore weaknesses and make improvements to schema
> design until we are happy with WAS Test 1.0
> Develop the Java and C# reference implementations
> Document
> 
> 
> 
> 
> 
> 
> 
> 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.