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