Re: [RFC] Vulnerability library proposal

[Daniel Miller <bonsaiviking () gmail com>]

Djalal, Rob,

Regarding XML script output and YAML, I submitted a revised, tested 
patch back in June (http://seclists.org/nmap-dev/2011/q2/1230) that 
drops the YAML idea for many of the same reasons Rob mentioned. Instead, 
it outputs more generic "container," "element," and "error" elements, 
with lines of output as CDATA contents. I haven't received any feedback 
on it, so it'd be great if you could test it out. I'm pretty sure most 
of the code it touches hasn't changed, so the patch should mostly be 
good. If it fails to patch, let me know and I'll spend some time 
bringing it up-to-date.

Dan

On 08/07/2011 12:30 PM, Djalal Harouni wrote:
> On Sun, Aug 07, 2011 at 11:10:45AM +0100, Rob Nicholls wrote:
> > Hi Djalal,
> Hi Rob,
> > This probably goes outside the scope, but what would the XML output look
> > like? It'd be great if we could somehow use the internal tags to create XML
> > tags to easily identify the state/risk factor/references etc. (to save us
> > from having to parse all of the script output first).
> For the XML support currently it's not easy. You know that Nmap will
> just put all the script output in the 'output' attribute of the 'script'
> tag.
>
> A clean solution would be to move all the NSE output code into a new file
> nse_output.cc and then try to create and register XML output there.
> Later the code will just inspect the registred XML data and write it
> under the 'script' tag. If you want to regroup _all_ the vulnerabilities
> XML output then a postrule script can do the job.
>
> And it would be awesome if you can propose a first XML output sample, so
> later we can start from it. Thanks in advance.
>
> > I know Daniel Miller has suggested (and even supplied) a YAML based
> > solution, but I find it easier to read a more traditional XML output, and I
> > generally use XPath to extract data from XML files generated by other tools
> > (at least Ruby has native YAML support, if I ever need to go that way). My
> I just did a quick look at YAML specification and it seems that we can
> support it. I remember that Daniel Miller submitted a patch but I don't
> know it state, if I've time I'll try to look at it.
>
> > concern is that the vulnerability data is crying out to be marked up to
> > allow for easy data extraction, and without it we're not really improving
> I agree.
>
> > that much over the existing output, but if we hack in support for additional
> > XML tags now for just the vulnerability data then would we make life more
> > difficult if we later decided to introduce  YAML (or other) output for all
> > NSE scripts. Personally, I like the idea of XML rather than YAML, especially
> > as it allows us to easily validate the Nmap XML files. It also avoids mixing
> > XML and YAML in the same file (I'd prefer it if the XML output just
> > contained XML; if people want YAML due to its good data representation then
> > maybe we should create a YAML output file?).
> As I've said we should start with a clean approach, move the output code
> into nse_output.cc file and do all the stuff there.
>
> If we have a better XML support in NSE then I think that the YAML output
> will not be mixed with the XML one.
>
> > Rob
> Thanks for the feedback.

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/