[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 ? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]