Re: [was] applicability?

[Rogan Dawes <rogan@dawes.za.net>]

OK, that's fine. I guess that it does make more sense for it to be 
grouped in the "detect" element.

Something like:

<Detect when="server"/> when we see a new server
<Detect when="path"/>   when we see a new path
<Detect when="file"/>   when we see a new file

e.g:

<Detect when="server">
<Variable name="path">
<Instance>/cgi-bin</Instance>
<Instance>/cgibin</Instance>
</Variable>
<Step>
<Request>
<Method>GET</Method>
<URL>${scheme}://${host}:${port}${path}/phf</URL>
<Version>HTTP/1.0</Version>
</Request>

etc

Seem OK?

Rogan

Mark Curphey wrote:

> Rogan
> 
> I think everyones heads down trying to get the Core complete by the end
> of the month and then I think (hope / know) everyone will turn their
> attention to Test (Detect). 
> 
> Applicability - I have two thoughts
> 
> 1. For WAS 1.0 I think it should be inside the Detect element and not
> inside core. I say that as it helps describe the test itself and not the
> signature
> 
> 2. I think it would be very useful in WAS 2.0 when we look at more
> generic patterns. As far as I am understanding, in WAS 1.0 we are
> describing the static conditions ala Nikto / Whisker. Whilst I can see
> this could also be useful, I think it would come into its own with
> generics. Either way I think it should be able to be overridden by the
> user.
> 
> Cheers
> 
> Mark
> 
> PS Hold on till May sir, Detect is next !
> 
> -----Original Message-----
> From: Rogan Dawes [mailto:rogan@dawes.za.net] 
> Sent: Thursday, April 22, 2004 12:40 PM
> To: was@lists.oasis-open.org
> Subject: [was] applicability?
> 
> I sent this message a few days ago, but got no response.
> 
> Hi folks,
> 
> I just wanted to check if there was any thought to "applicability"
> markers in the current core schema? I don't see anything of the sort in
> the current schema checked into the OWASP WAS repository.
> 
> By applicability I mean, this test should be executed when we see a new
> server (or new server:port pair), that test should be executed when we
> see a new directory entry, the other test should be executed when we see
> a new file entry.
> 
> This is useful as an initial filter for tests that should be executed,
> and also allow us to know which URL components to expect to be valid
> when we try to execute the test itself. I think it is quite important to
> provide this information to execution engines, so that they can optimise
> their execution of the various tests.
> 
> for example, you can always expect meaningful "${host}" and "${port}"
> values, but "${path}", "${file}" and "${extension}" may be non-existent
> at times.
> 
> Some examples of tests that would be executed at each level:
> 
> server:port -> existence of well-known cgi's, a la Nikto/whisker
> path -> existence of accessible .htaccess files in that dir
> file -> existence of ${file}.bak or ${file}.old, etc
> 
> Please consider including such a tag/description in the test meta data. 
> Alternatively, do you think that this information should actually be 
> part of the Test data, and has no place in the Meta-data as such?
> 
> Thanks
> 
> 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.
>