OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

was message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [was] applicability?


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

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



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?



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]