Hi Is there a particular reason why the output plugins don't implement the logEnabledPlugins method? The outputManger doesn't forward the method call to the plugins. I need this for the xml output. How would you rather like it:
1) Adding the logEnabledPlugins method to the baseOutputPlugin and to every output plugin 2) Adding something like this into the outputManager: for oPlugin in self._outputPluginList: try: oPlugin.logEnabledPlugins(enabledPluginsDict, pluginOptionsDict) except: pass Cheers, Kevin ---------------------------------------- > Date: Wed, 17 Dec 2008 11:16:54 -0200 > From: andres.rian...@gmail.com > To: muff...@hotmail.com > Subject: Re: [W3af-develop] XML Output Plugin > CC: w3af-develop@lists.sourceforge.net > > Muffys, > > 2008/12/16 Muffys Wump : >> >> Hi Andres >> >>> Date: Mon, 15 Dec 2008 08:16:34 -0200 >>> From: andres.rian...@gmail.com >>> To: muff...@hotmail.com >>> Subject: Re: [W3af-develop] XML Output Plugin >>> CC: w3af-develop@lists.sourceforge.net >>> >>> Kevin, >>> >>> On Mon, Dec 15, 2008 at 7:17 AM, Muffys Wump wrote: >>>> >>>> Hi everyone, >>>> >>>> I wrote a xml output plugin for further automation of w3af scan results. >>>> I'm going to commit this if everyone is okey with the overall xml structure >>>> (see the report.xml attachment). Debug messages can be disabled. >>> >>> Once again, thanks for an excellent contribution =) >>> >>> Some comments: >>> >>> - I think that w3af should provide only one single way of writing an >>> HTTP log to a file, so the xmlFile plugin should have a "pass" as the >>> implementation for the "logHttp" method. And all the things related to >>> that feature should be removed from the plugin. Users should know that >>> THE way of writing HTTP request and responses to a file is using >>> textFile plugin. Also, if we keep this feature in both plugins, and in >>> the feature one plugin changes the way of doing it... we'll have two >>> different formats for the output file that handles HTTP logs! (which >>> sucks!) >>> >> Okey... But then you need to remove it from the html output plugin as well. > > Excellent point! I just did that. > >>> - "self._reportDebug = False" is a good choice. >>> >>> - Please try to use underscore separated variables and method names >>> >>> - Writing the XML file this way: >>> >>> # Add additional information results >>> for node in self._consoleXML: >>> self._topElement.appendChild(node) >>> >>> for node in self._debugXML: >>> self._topElement.appendChild(node) >>> >>> for node in self._errorXML: >>> self._topElement.appendChild(node) >>> >>> Will confuse people, because items are going to be out of order! >>> People don't expect grouped messages, they expect to see events as >>> they happen, mixed. The solution would be to do something like this: >>> >> I don't quite agree with you. My goal with this plugin was to create a >> machine >> readable format of the most essential events that occured during a scan. A >> user >> should not use this plugin as a replacement for the text or console output. >> The xml output >> could for example be used in a script which parses the xml and sends an >> email to a project manager in case >> of a vulnerability. In this case the order of the events doesn't matter. >> Realy like the html output which is >> ordered as well. > > Ok, good point. Don't modify this. > >>> # Add additional information results >>> for node in self._general_list: >>> self._topElement.appendChild(node) >>> >>> Or even better... why don't we DIRECTLY write to _topElement inside >>> each "information", "debug", etc method? If we write directly to the >>> _topElement, we are going to be saving some memory because things are >>> written to the file, right? If not... is there a way to write things >>> to the file and not store them in memory? >>> >> >> Usually the dom tree gets built in memory but I can code it differently >> to save memory. > > If debugging is enabled, and you save all debugging messages to > memory, during a long scan... w3af will use something in the range of > 100mb to 1000mb of memory if all debug messages are saved to memory. > So... yes, if it's possible please perform some refactoring in order > to be able to reduce memory usage. > >>> - This line doesn't look really nice: >>> >>> target="http://localhost/vuln/index.php"/> >>> >>> xss, w3afCore and baseGrepPlugin mixed in the same line? It makes no >>> sense to me as a developer, and it will make no sense for the users >>> either. Maybe the scan info should look like: >>> >>> >>> >>> >>> >>> >>> >>> >>> ... >>> >>> >> >> Okey, I'll change that accordingly. > > Cool =) > >>> Your contribution was really good, but it needs some work, right now I >>> don't have more time to test the plugin :( >>> Please try to fix the items in my list, and then re-post the results >>> here. THANK YOU! >>> >>> Cheers, >>> >>>> Cheers, >>>> Kevin >>>> >>>> _________________________________________________________________ >>>> Discover the new Windows Vista >>>> http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE >>>> ------------------------------------------------------------------------------ >>>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. >>>> The future of the web can't happen without you. Join us at MIX09 to help >>>> pave the way to the Next Web now. Learn more and register at >>>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >>>> _______________________________________________ >>>> W3af-develop mailing list >>>> W3af-develop@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/w3af-develop >>>> >>>> >>> >>> >>> >>> -- >>> Andres Riancho >>> http://w3af.sourceforge.net/ >>> Web Application Attack and Audit Framework >> _________________________________________________________________ >> Discover the new Windows Vista >> http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE >> >> ------------------------------------------------------------------------------ >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. >> The future of the web can't happen without you. Join us at MIX09 to help >> pave the way to the Next Web now. Learn more and register at >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >> _______________________________________________ >> W3af-develop mailing list >> W3af-develop@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/w3af-develop >> > > > > -- > Andres Riancho > http://w3af.sourceforge.net/ > Web Application Attack and Audit Framework _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
