> > 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
theme_vulns.dict
Description: Binary data
wordpress_fingerprint.py
Description: Binary data
wordpress_theme_auditor.py
Description: Binary data
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
