Same as with the HPP stuff, this has been sitting in my inbox for way
too much time. Created this issue so that everyone can follow up:
https://github.com/andresriancho/w3af/issues/168
On Fri, May 4, 2012 at 11:10 AM, Stephen Breen <breen.mach...@gmail.com> wrote:
>> Usually we keep things like that in
>> "plugins/discovery/<plugin_name>/foo.bar" , in your case it would be
>> something like "plugins/discovery/wordpress_theme_auditor/" (please
>> note the change in the plugin name I'm also suggesting).
>>
>
>
> Ok, done and renamed. The dictionary is now in a separate text file which is
> read in, theme_vulns.dict
>
>>
>> I wasn't clear enough, sorry. I was referring to the process of
>> finding the wordpress root. We don't want to try to find the wordpress
>> root in all wordpress plugins, we just want to do it in plugin "A",
>> have that data stored in the KB, and then the rest of the plugins that
>> depend on "A" will simply read the data from the kb.
>
>
> Oh okay, that makes sense. The wordpress_fingerprint plugin does find the
> wordpress root. It uses the same technique I was (looks for wp-login.php)
> but simply relies on the is_404 function returning false. I think this is
> probably fine most of the time. I've made a modified version of this plugin
> that adds the wordpress_root to the kb, and my plugin now reads it from the
> kb.
>
> It looks like the wordpress_fullpathdisclosure plugin also tries to identify
> the currently running theme, but after some testing this functionality seems
> to be broken (at least in the case I tested) and I'm not sure why right now.
> I've decided to keep my own code to find the running theme for now.
>
>>
>>
>> Not sure about the regex, didn't had time to review it, but I'll
>> believe you if you say it works :) Also, if possible please compile
>> regular expressions only once and then use them. An example would look
>> like this:
>>
>> class pluginx(...):
>> CSS_RE = re.compile(...)
>>
>> def search_css(...):
>> ...
>> self.CSS_RE.search( some_text )
>>
>
> Done, compiled that regex. The other ones are constructed dynamically so
> I'll have to leave them. Thanks, I didn't know python regex's could be
> compiled! I'm pretty new to the language but really like it, turning out to
> be one of my favorites.
>
>>
>>
>> Yep, but yours also checks for a vuln... we want to keep that. I would
>> recommend merging the identification of the theme into
>> wordpress_fingerprint and then having the detection of the
>> vulnerability in a second plugin that depends on
>> wordpress_fingerprint.
>>
> Hmm if we are keeping the separate plugin for theme auditing anyways, maybe
> it should all just stay in the new one. The theme enumeration and checking
> for vulnerabilities are pretty tightly coupled (the dictionary that stores
> the themes to enumerate also stores which vulnerabilities each might be
> subject to since they are theme specific).
>
> New code is attached for wordpress_fingerprint and wordpress_theme_auditor
> and the theme_vulns.dict which is the text file that gets loaded with the
> themes and their vulnerabilities. It goes under
> plugins/discovery/wordpress_theme_auditor
--
Andrés Riancho
Project Leader at w3af - http://w3af.org/
Web Application Attack and Audit Framework
Twitter: @w3af
GPG: 0x93C344F3
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
