Proposed XML Schema for AVDL 2003-09-27 Proposed XML Schema for AVDL 2003-09-27 Copyright © OASIS Open (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Here we import the XHTML 1.0 namespace so we can use it where human readable documentation is presented. Import the xml: namespace to get access to the xml:lang attribute groups so we can use it within 'comment-type'. This is the root element of an AVDL document. It contains a series of blocks, comments, and probes. Each <block> describes a chunk of information such as a <session>, a <vulnerability>, etc. <probes> are a type of <block> that in addition can be nested inside a <session>. The version of the AVDL standard. Should be 1.0 for the first recomended version The identifier of the vendor or system generating the AVDL output to follow. (i.e. SPI,CITADEL,NETCONTINUUM) Key declaration for elements with block-id to ensure uniquenes within the AVDL file. This type is extended by almost all avdl types to allow attributes from other namespaces to be added to elements. This type is extended by almost all types which allow comments (other than <avdl> itself and a few special cases). A globally unique identifier for this block. An item of meta data. An item of meta data. HREF datatype container. Queries HTTP headers. Describes HTTP headers. Used to query the HTTP status line. If the 'name' attribute is left out, the value is expected to hold the whole line instead of one of the three fields. Used to document the components of an HTTP status line. If the 'name' attribute is left out, the value is expected to hold the whole line instead of one of the three fields. A test or a boolean operation such as or. Sequences of clauses are combined with an implicit and operation between them. Parameter definition type. This is a way of describing raw data. Base type for parsed data. Base type for parsed requests. Base type for parsed responses. Parsed response data for http. Parsed response data for http. Classifies the request type. Classifies the request type. Classifies the basic http message type. Expands variable references and allow special markup. Describes what to do with an http response Classifies the basic http transaction type. This is the abstract base-type for blocks. This defines data common to all blocks. A short one sentence summary. We allow multiple instances of summary for different language versions. A full description. It is possible to use XHTML markup here. We allow multiple instances of description for different language versions. Example: <classification xmlns:was="urn:oasis:..." type="was:severity" value="was:really-really-bad" /> Name-type-value triplets of meta data. Reference(s) to earlier version(s) of this block, or documents it is based on. Some kind of version description of the block. A human readable name. Does not have to be unique. A globaly unique id for this block. This is the base-class for probes. A probe is the result from a scanner completing one transaction against the probed site. A transactions can involve several steps and can cross protocols. (E.g., a login to a site might start as HTTP and end up using HTTPS.) The descriptive elements -- if present -- are only used as documentation when inside a probe. An absolute or relative (to the start of the session) time stamp. An reference to the session. This attribute is only allowed if the block is used at the top level, and the it is required. (I.e., don't use for blocks already nested inside sessions.) Indicates if a traversal step succeeded or not. This allows documentation of unreachable nodes by setting this attribute to false. Allows the probing or traversing engine to indicate what it expected to see. For example, following a link, the expectation would be "success", but checking for a vulnerability, the expectation would be "failure". This contains both the text of the comment and any XHTML tags used to enhance it. This allows any number of elements from any namespace outside of the AVDL space. This contains a simple text summary with an optional language attribute. A base container for all remediation specific information. A patch description with name and HREF link. A user description. Used to describe special characters used in raw blocks. A test-script specification. Base target description container. A simple data type that can be validated, or a QName. A simple data type to contain all regular expression formats. TODO: need to extend this further. A simple data type that can be tested for, and validated. [0-9]+ [+-]?[0-9]+ [+-]?[0-9]+(\.[0-9]*)?([eE]-?[0-9]+)? There is no support for validating NaNs or infinities. [-]?[0-9]{4,}(-[0-9]{2}){2}(Z|[+-][0-9]{2}:[0-9]{2})? [0-9]{1,2}(:[0-9]{2}){2}(\.[0-9]*)(Z|[+-][0-9]{2}:[0-9]{2})? [-]?[0-9]{4,}(-[0-9]{2}){2}T([0-9]{2}:){2}[0-9]{2}(\.[0-9]*)(Z|[+-][0-9]{2}:[0-9]{2})? anything A non-negative integer or the string "unbounded". Used for max-length. Timestamps as either absolute (xs:dateTime) or relative (xs:decimal as seconds since the sessions session-start). RFC 2616 section 5.1.1 Describes the expectation as to the result of some operation. The operation is expected to succeed. The operation is expected to fail. There is no expectation, neither positive, nor negative, as to the result of the operation. Describes the persistence property of a href. The href link is exportable (or visible) outside. The href link is non-exportable, dies when the session expires. Describes the href type. The href link is a static link. The href link is dynamically generated. Together, these elements can describe a target specification, a test-script to run, and possible recommendation(s). Mostly one would expect to see them in something like a vulnerability-description, but they can be included inside a probe as documentation. An explicit <and> grouping of validation clauses. An explicit <or> grouping of property clauses. Invert the meaning of the nested property clause Enumerates the basic ways of marking a raw block. Indicates a protocol appropriate end-of-line. Indicates a protocol appropriate end-of-line. Indicates a protocol appropriate space. This is useful to represent sequences of more than one space, since the whitespace in the raw block is normalized. Indicates one character in the encoding specified by the protocol. A chunk of base64 data in the encoding specified by the protocol. (See RFC2045) A chunk of hex data in the encoding specified by the protocol. Enumerates the extended ways of marking a raw block. Substitutes the value of a variable. Marks an attack component. Possible comparision operations. One and only one of these attributes may be present at the same time. Equality. Not equal (exact inverse of <equals>). Matches substring. Does not contain (exact inverse of <contains>). Less than Greater than Less than or equal (exact inverse of <greater-than>). Greater than or equal (exact inverse of <less-than>). Maximum length of data. Minimum length of data. Validated type Specifies if the parameter is required or not. If required is true and the parameter is not present, then return false. All other combinations returns true. Compare using regular expression Does not match using regular expression (exact inverse of <regex>). Match using pattern where '*' matches anything. Does not match using pattern where '*' matches anything (exact inverse of <match>). This declares the scope that the name of key attribute is evaluated in. A sequence number. A reference to the direct parent of this step. Defines how we got here (external entry point, local reference, etc.) This steps identity. Each one of these modifiers helps control compare operations. Normally it is assumed that the value is normalized as if it was of type xs:token, but if preserve-space is true, then preserve whitespace. By default, all magnitude comparisons are compared using lexical magnitude. If 'numeric' is true, then the comparision will be using numeric magnitude whenever possible. If this is true (the default) then lexical comparision is done while ignoring case. This is the abstract base for all root-blocks. This is the abstract base for all session-block. This is the abstract base for all traversal-protocols. This is the abstract base block for all test configurations. This is the abstract base block for describing vulnerability descriptions. This is the abstract base block for describing vulnerability probes. This is the base for all statements. This is the base for all transaction statements. This is the base for all statements in transaction responses. This is the abstract base for all validation clauses. Each session contains one of these blocks and other blocks related to it (such as probes) have references to its ID. A URI that describes the host or hosts that this session was run against. An absolute time stamp as to when this session was initiated. This is the base-class for vulnerabilities. This is the base-class for stepwise traversals (such as an enumeration of accessible URL's at a given site).. A probe is the result from a scanner completing one transaction against the probed site. For example, each URL in a web-spiders crawl would show up as one probe. This is the base-class for all test related stuff. Describes the test-script for a vulnerability. It contains a series of clauses. A test specification. A remediation specification. Describes how a traversal was performed, and the result. Describes how a http probe was performed, and the result. Test the current parameter for a value. Only one of the attributes from the op attribute group is allowed at a time. This is the base for all execution blocks. HTTP based transactions. HTTP based transactions. This is the base for all execution blocks. This is the base for the expect block. Jan Bialkowski Srinivas Mantripragada Johan Strandberg