Luca Andreucci <[EMAIL PROTECTED]> writes:
> Wouldn't it be better for localized parts of the plugs to be kept
> aside from the source at all, in a separate data structure (maybe
> shared between plugs)? Of course I can see downsides, but there
> would be a lot of benefits IMO.
>
> How this would be accomplished (and kept in sync) is left as an
> exercise to the reader :-))
I agree, the plug-in code should be separated from the metadata (data
about the plugin, including CVE numbers, categories, descriptions in
various languages, etc.). Embedding the metadata inside the code is
not pretty, and causes problems when other tools than Nessus need to
use that data (e.g. various scripts for gettings CVE numbers etc. out
of Nessus plugins).
I suggest the metadata should be placed as an XML document in the same
file as the plugin (so keeping them in sync with the code won't become
a huge problem). E.g. something like this (BTW, I'm not XML schema expert,
so don't consider this a good example :)
<nessus-plugin>
<plugin>
# information about the plugin itself
<id>10544</id>
<version>$Revision: 1.10 $</version>
<dependencies>
<script>rpc_portmap.nasl</script>
<key>rpc/portmap</key>
# eventually the script name could be found automatically, if
# rpc_portmap.nasl had some kind of "<provides>rpc/portmap</provides>"
# tag
</dependencies>
<author>Renaud Deraison</author>
# also category/safety information
</plugin>
<vulnerability>
# information about the vulnerability this plugin tests for
<references>
<cve>CVE-2000-0666</cve>
</references>
<severity>High</severity>
# could be something better, as has been discussed on the mailing
# list during the last week
<name language="en">format string attack against statd</name>
<description language="en">
...
</description>
<description language="fr">
...
</description>
</vulnerability>
</nessus-plugin>>
# NASL code starts here
Ok, this does not completely solve the problem, as some plugins
generate the text to be printed during run time, but maybe
that could be handled somehow as well...
The XML would be reasonably easy to parse with other programs, and it
would be extensible -- we could add new fields easily which would be
ignored by programs which don't understand them. For instance, whether
some plugin has been well tested or not tested at all, or if the NASL
and description have been inspected by someone or not, information
about false positives, etc. (wishful thinking, perhaps :-)
Regards,
Pasi
--
Pasi Eronen E-mail [EMAIL PROTECTED]
Nixu Oy Tel +358 50 5123499
M�kel�nkatu 91, 00610 Helsinki Fax +358 9 4781030
-
[EMAIL PROTECTED]: general discussions about Nessus.
* To unsubscribe, send a mail to [EMAIL PROTECTED] with
"unsubscribe nessus" in the body.
