XSS Vulnerability in Democracy Wordpress Plugin
Aaron Brazell just published an interesting post talking about a cross site scripting vulnerability in the democracy plugin for Wordpress. Almost immediately after posting Democracy published a fix to the vulnerability. This is a pretty interesting flaw that I think needs a little more discussion.
Firstly, I think it’s important because Wordpress is not to blame for this issue. No, it’s an independant plugin author who is to blame. It’s very similar to the problems in Firefox that we’ve been exploring over the last few weeks - again, not Firefox’s issues, but the plugins themselves. It’s a little concerning that there is less and less information about system security as more addons are built on top of platforms. There’s next to no way to tell if you have hurt your security integrity without thorough code review of not just the plugin but how it interacts with other plugins, etc… A daunting task.
The other interesting part of this is that it isn’t reflected XSS, but rather it is persistant. This is also pretty useful for search engine optimization (SEO). Splogging isn’t particularly useful anymore (having spoken about the issue with one splogger about it). But XSS is in (if it’s persistant). In this case it isn’t exactly cross domain, but by including a simple <A HREF=http://spamsite.com>keyword</A> they suddenly get persistence on the front page of whatever domain they are interested in, giving them a high pagerank link to their domain from the main page. That’s one of the worst XSSs I’ve seen for that very reason, even if it’s not used as XSS but rather just straight HTML injection.
For SEO it is far more useful to be able to have stored links on the front page than sub pages. And while the author has suggested an upgrade, existing installs will be slow to upgrade most likely, so there is still a large opportunity of existing install base for blackhat SEO types to use this flaw to their advangage. For the blackhat hacker types, they can do cookie theft and log into the administrator account. Either way, it’s nasty.
Thanks to Aaron for helping me test this issue.
September 23rd, 2006 at 9:56 pm
Firstly, I think it’s important because Wordpress is not to blame for this issue. No, it’s an independant plugin author who is to blame. It’s very similar to the problems in Firefox that we’ve been exploring over the last few weeks - again, not Firefox’s issues, but the plugins themselves.
I think that’s always a risk when you install addons. Not only can vulnerabilities in the original product get you hacked, but so to can vulnerabilities in the addons you’ve installed.
The fact that you also have that many more things that need to be kept up-to-date makes maintaining a script with a ton of addons rather tedious. Instead of just having to check one website, periodically, you have to check multiple ones, etc.
September 23rd, 2006 at 9:58 pm
Exactly… and how can anyone do that reliably? Firefox does a good job of making that easy (if you know to check for updates) but still you still have to know how to do that and think to do that. These sorts of plugins don’t auto-update (nor should they) but it’s certainly not fool-proof.
September 23rd, 2006 at 10:57 pm
Of course, educating non-developers to potential risks is a huge hurdle as well. Most people use software because it helps them accomplish something easier. They use Firefox because it does a lot to prevent phishing, popups and adware. They use WordPress because its a simple install, low-tech interface that allows them to simply write and gets out of the way.
Addons and plugins are great because they make whatever the task is that much easier. The sorts of issue I wrote about is unfortunate because it discourages people from exploring the full capability of their software. It’s like walking around in a dark unfamiliar room before your eyes adjust. You walk super cautiously with your arms flailing around int the dark trying to find a light switch and not walk into a dresser.
The trick is trying to demystify security issues that are muge and in many ways mysterious without turning off the willingness to explore these extensions. Tough nut to crack.
September 24th, 2006 at 10:23 am
Perhaps the core developers should have a more active hand in the development of these extensions. They may be extensions, but they should be maintained just like fixtures in the regular codebase.