9 Goals from WAS XML ?

These are my thoughts on some goals from the 
perspective of someone who has looked at VulnXML, and focusing on the part 

of the signature that describes the sequence of test operations (ie not the 
classification scheme or risk ranking model).

 

Improved i18n/localization Support
A good deal 
of human readable text is contained in the signature; the format needs to 
support the provision of this 
text in multiple languages.

 

Richer Core Functionality
In order for the 
signature to support a more diverse set of tests, the format needs to support a 
wider range of operations, 
such as scoped variables, enhanced conditional 
logic, repetition.

 

Improved Code Reuse Mechanism
There needs to be 
a way to for WAS-XML signature authors to package common functionality for reuse 
in many places within a 
signature or in many signatures.  Need 
subroutines, functions or methods, and an inclusion mechanism.

 

Improved Extensibility
It must be possible for a 
3rd-party to extend the functionality offered in the core WAS-XML feature 
set.  The extensibility 
mechanism could be modeled on the one used in 
XSLT.

 

Structured Extended Output Information
Tests 
need to return more than pass/fail -- there should be structured 
(machine-readable) sections and loosely-structured 
sections (human-readable 
information). More information is needed so that systems and users can, if 
needed: determine cause 
of test failure, determine if result is really 
benign/malignant, understand details of test processing.  The information 

needs to be structured so that a system can present the information in a 
meaningful way or perform further processing on 
the data.

 

Tighten Schema
It looks like this is already 
happening as part of WAS-XML (classification XML Andy Jaquith started) , but the 
more 
restrictive the schema can be made, the more easily documents will 
be
processed and authored using standard XML authoring tools.

 

ApplicableTo Element
Running only the tests that 
are applicable to a given platform/OS/web server/application should yield 
considerable 
performance and coverage
benefits in an enterprise-class 
system.  It is important that WAS-XML signatures have an ApplicableTo-like 
section so that 
systems can optionally try to run only the signatures judged 
to be applicable.  However, the VulnXML ApplicableTo element 
and its 
sub contents can be quite complex --  for the WAS-XML Signature author 
perhaps too complex.  I wonder if it might 
be possible to create a 
simpler but equally expressive alternative to the VulnXML ApplicableTo 
element.

 

Less Novel Approach
VulnXML essentially defines 
its own simple procedural programming language. As Jeff and others have pointed 
out this is 
crucial in testing. I believe the language must necessarily 
become more complex to cover the range of web application 
testing 
scenarios.  Rather than extend a new and relatively unknown programming 
language, why not adopt an existing 
programming paradigm (XSLT or JSP+custom 
tags) or adopt a widely used programming language (JavaScript)? XSLT would be my 

strong preference although we may wish to support several. 

 

Integrity of Signature
A mechanism to proove 
that the signature originated from a trusted source and has not been modifed. 
XML Dig SIg ?