[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [was] WAS Test
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]