WAS Executor, Connection, ThreadGroup and functions

["Dawes, Rogan (ZA - Johannesburg)" <rdawes@deloitte.co.za>]

Hi folks,

I made some progress on the WASExecutor last night. 

Currently it can read in a test (iff I hard code the DTD url :-(), calculate
all the variations based on the variables defined, create a request with all
the variables interpolated appropriately, and gets the response from the
server.

Now I just need to implement the pattern matching against the response, and
the testing of variables against the criteria, and we are good to go.

I have taken a few shortcuts on the way. For example, I have not implemented
the various "encodings" for various fields. I think that can wait until I
have the variable matching and testing done. At least we can start
discussing the actual WAS language, even if that part is not yet done.

I have already had a couple of thoughts, based on the development of the
Executor:

<Connection> is pretty much redundant, I think. If we were to format the URI
as "${scheme}://${host}:${port}${path}/$file" (i.e. include the scheme host
port in the URI, rather than separately), we should be OK.

The initial reasoning behind the Connection element was to specify
conversations that have to take place in the same TCP or SSL connection. But
it should be possible (easier?) to implement by testing for "Connection:
Keep-alive" and "Connection: close" headers as well.

The other thing was with regards to reporting success and failure. We said
that we want to be able to describe positive as well as negative states. In
that case, simply having "test fail" and "test success" does not provide
enough information about whether to include the test as a vulnerability or
not.

I seem to recall that I had a "ReportOn" element in the earlier versions of
the DTD, but it doesn't seem to be there any more. I think we need to
resurrect it, for this purpose.

Finally, I was thinking about the issue of threading multiple requests.

Perhaps we could have a <Thread delay="ms"> element that contains 1 or more
<Step> elements, and a final <TestCriteria> element. <Thread> could appear
instead of a <Step> element.

The idea being that when the executor encounters a Thread element, it
creates a new thread, sets it to delay for the specified length of time,
then executes the enclosed steps, setting variables, and testing criteria.
It would generally only make sense to have more than one adjacent <Thread>
element, otherwise one might just as well execute the Steps in the parent
thread, if you know what I mean.

i.e. 
<Test>
<ThreadGroup>
  <Thread delay="0">
    <Step>
      <Request>
      </Request>
      <Response>
      // set thread1 variable
      </Response>
      <TestCriteria>
      </TestCriteria>
    </Step>
  </Thread>
  <Thread delay="0">
    // another Step or set of steps
      <Request>
      </Request>
      <Response>
      // set thread2 variable
      </Response>
      <TestCriteria>
      </TestCriteria>
    </Step>
  </Thread>
  <TestCriteria>
    // did the two threads execute successfully?
    // check against the thread1 variable and the thread2 variable, for
example
  </TestCriteria>
</ThreadGroup>
</Test>

Obviously I have left out certain elements for the sake of clarity.

Thoughts?

The last thing I am thinking of is the discussion that we had with regards
to the level of functionality required in terms of operators, functions,
etc. One approach might be to define certain functions that a
compatible/compliant implementation needs to provide. Those could be
synchronised with the DTD version, for example.

An example of some functions that might be useful:

repeat(${variable}, count) or repeat(char, count)
base64encode(${variable})
base64decode(${variable})

Does anyone have any other ideas of how to support this kind of flexibility?
Or do we really need to?

Thanks

Rogan

-- 
"Using encryption on the Internet is the equivalent of arranging an 
armored car to deliver credit card information from someone living 
in a cardboard box to someone living on a park bench."
  - Gene Spafford
-- 
Deloitte & Touche Security Services Group
Tel: +27(11)806-6216     Fax: +27(11)806-5202     Cell: +27(82)784-9498
-- 

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.