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