RE: [was] How is Test (Detect) progress ?

[Yuval Ben-Itzhak <yuvalben@netvision.net.il>]

It looks ok now.

Here is another issue:
<xs:attribute name="versionRevisionDateHistory" type="xs:dateTime"
minOccurs="1"/>

The tag 'attribute'  does not support an attribute of 'minOccurs'. It should
be remove, associated with the parent 'element' or be structure differently
to represent the "versionRevisionDateHistory" elements - if needed.

More reading regarding the 'attribute' can be found:
http://msdn.microsoft.com/library/en-us/xmlsdk/htm/xsd_ref_460k.asp


Yuval.

-----Original Message-----
From: Nasseam Elkarra [mailto:nelkarra@opensec.org]
Sent: Tuesday, March 30, 2004 10:52 PM
To: was@lists.oasis-open.org
Subject: RE: [was] How is Test (Detect) progress ?


An element cannot be a child of a complexType, you are going to have to
put it into a element container (e.g. sequence element). Also, elements
that have attributes are considered complexTypes and must be defined as
such. The following should validate correctly:

<xs:complexType>
  <xs:sequence>
    <xs:element name="thesaurusEntry">
      <xs:complexType>
        <xs:attribute name="thesaurusGroupName" type="xs:string" />
        <xs:attribute name="thesaurusSubGroupName" type="xs:string" />
        <xs:attribute name="additionalInformation" type="xs:string" />
      </xs:complexType>
    </xs:element>
    <xs:element name="vulnDatabase">
      <xs:complexType>
        <xs:attribute name="databaseName" type="xs:string" />
        <xs:attribute name="databaseLocation" type="xs:uri" />
        <xs:attribute name="databaseRef" type="xs:string" />
      </xs:complexType>
    </xs:element>
    <xs:element name="shortDescription" type="xs:string" />
    <xs:element name="longDescription" type="xs:string" />
  </xs:sequence>
</xs:complexType>

--Nasseam

> -----Original Message-----
> From: Yuval Ben-Itzhak [mailto:yuvalben@netvision.net.il]
> Sent: Tuesday, March 30, 2004 9:46 AM
> To: Mark Curphey; Rogan Dawes
> Cc: was@lists.oasis-open.org
> Subject: RE: [was] How is Test (Detect) progress ?
>
>
> Hi,
>
> I'm trying to sync. was-core0.3.xml (a Schema) to VulnXML-1.4.dtd for
the
> Detect project.
> It appears that although was-core0.3.xml is a valid XML document it is
not
> a
> valid Schema.
>
> Check the following ComplexType:
>
> <xs:complexType>
> 	<xs:element name="thesaurusEntry" use="required">
> 		<xs:attribute name="thesaurusGroupName"
type="xs:string"/>
> 		<xs:attribute name="thesaurusSubGroupName"
type="xs:string"/>
> 		<xs:attribute name="additionalInformation"
type="xs:string"/>
> 	</xs:element>
> 	<xs:element name="vulnDatabase">
> 		<xs:attribute name="databaseName" type="xs:string"/>
> 		<xs:attribute name="databaseLocation" type="xs:uri"/>
> 		<xs:attribute name="databaseRef" type="xs:string"/>
> 	</xs:element>
> 		<xs:element name="shortDescription" type="xs:string"/>
> 		<xs:element name="longDescription" type="xs:string"/>
> 	</xs:complexType>
>
> It looks to me that the complextype should include attributes and not
> elements (see other ComplexTypes in the Schema). An element is a
parent
> 'element' of a complextype.
> I used an eval of XMLSPY and it alerts on the same issue.
> Here is a reference from MSDN:
> http://msdn.microsoft.com/library/en-us/xmlsdk/htm/xsd_ref_9qpg.asp
>
> Any comments ?
>
>
> Yuval.
>
> -----Original Message-----
> From: Mark Curphey [mailto:mark.curphey@foundstone.com]
> Sent: Monday, March 29, 2004 4:08 PM
> To: Rogan Dawes; yuvalben@netvision.net.il
> Cc: was@lists.oasis-open.org
> Subject: RE: [was] How is Test (Detect) progress ?
>
>
>
> See comments inline.
>
> I think we need to move towards putting this schema under version
> control.
>
> CVS OK with everyone ?
>
> That said I think you Test folks and Protect folks (Ivan) should
develop
> a separate schema and we will integrate it later. This will ensure we
> get less merge conflicts etc. Maybe you can name it WAS-Detect-c.xsd,
> WAS-Protect-x.xsd ? You can upload it to the OASIS site as well for
now
> until we get the CVS setup.
>
> Also I chatted to Ivan about Protect and wanted to facilitate a
> conference call to ensure we don't overlap and reuse as much as is
> possible.
>
> See other Comments inline
>
> -----Original Message-----
> From: Rogan Dawes [mailto:rogan@dawes.za.net]
> Sent: Monday, March 29, 2004 6:09 AM
> To: yuvalben@netvision.net.il
> Cc: Mark Curphey; was@lists.oasis-open.org
> Subject: Re: [was] How is Test (Detect) progress ?
>
>
>
> Yuval Ben-Itzhak wrote:
>
> > As I refresh my memory with all the DTDs and Schemas that are
> > available, I found that there are many overlaps between the current
> > VulXML DTD
> > (VulnXML-1.4.dtd) and the Meta schema (oasis-was-version4.xsd). In
> > addition, the two will need to be in Sync. with the Thesaurus schema
> > (could not find an available schema) as they all reference each
other.
>
> Yes, there are a number of overlaps. The WAS-Core schema that Mark and
> co have been working on replaces the <TestDescription> element of
> VulnXML completely, I think.
>
> The section that we need to aim for with Test is the part of VulnXML
> that starts at <Variable>*, and continues with <Connection>+, where *
> indicates optional element, and + indicates one or more Connection
> elements.
>
> MC > Exactly. This allows Protect and Detect to use the same textual
and
> meta-data so its all consistent. The work you Detect folks are doing
> should be on the Test Case only and not the descriptive or signature
> management pieces.
>
> >
> > 1. The initial work is to do some 'clean-up' and 'sync.' between the
> > documents as well as to have them all with the same format (I prefer
> > Schema). I remember that in the early days of OWASP, Altova (XMLSpy)
> > contributed a license/s - is this still available? can I have it for
> > this task?
>
> Not sure if it is still available. Mark?
>
> MC > We all agreed this should be developed in Schema.
>
> No its not. Well at least not the new versions. If you have VS.NET its
> pretty decent or if you havent used SPY before you can get a 30 day
> trial. Also there are a number of good Java based editors now. I will
> send a mail with the ones I know about.
>
> >
> > 2. After this work, in my opinion, the VulnXML will need to be
updated
>
> > to support all "vulnList" defined in the Meta schema. Currently I
> > could not see how it will support some of the DoS and Injection
types
> defined on the Meta.
>
> Just a reminder, because I'm not sure that Yuval and I are on the same
> page with regards to how/why VulnXML was designed:
>
> The intention with VulnXML was not to create "functions" that would
> automatically expand into a test for a SQL injection in one of almost
> infinite permutations. VulnXML was designed to document the exact
steps
> that one would go through to replicate a test that has been done
before.
>
> This is typical of tests for static vulnerabilities, much as Whisker
and
> Nikto do. This is the problem that VulnXML was intended to solve, and
> the intention of WAS-XML as well.
>
> MC > Perfect
>
> WAS-XML is not intended to describe how to automatically compose
> multiple tests for a SQL injection on an arbitrary form (or XSS, or
> whatever). It is intended to facilitate the interchange of known
> vulnerabilities between tools.
>
> MC > Exactly. WAS 2.0 may though !
>
> So, there are some aspects of the current VulnXML schema/dtd that
would
> need to be refined, but we do not need to code explicit support for
each
> of the categories mentioned in Mark's schema. If it can be expressed
as
> an HTTP Request (request line, headers and body), and tested for in
the
> HTTP Response (status line, headers or response body), we should be
able
> to express anything we want to.
>
> MC > That's true. Remember WAS will have support to describe issues
that
> maybe found in code by code scanners (issues that cant be found by
black
> box scanners. It is the generic vuln description language that people
> can build business process around as well as taking feeds from
> technology and tools. We shouldn'y insist on a Detect or Protect
> signature for every vuln that would be descibed in Meta IMHO.
>
> However, as mentioned in previous mails, outstanding items that are
> *NOT* currently possible are multiple simultaneous requests for
testing
> locking or synchronisation issues, and reliable/intelligent detection
of
> custom 404 responses. These still need to be added to the Test
elements
> of WAS-XML.
>
>
>
> > My current goal is # 1
> >
> > Yuval.
> >
>
> Regards,
>
> Rogan
>
> 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
> .
>
>
>
> 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.



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
.