As I’ve explained before, cross-site scripting (XSS) flaws are a big problem on the net.
Vulnerable websites can be exploited via XSS to steal user accounts, change settings or phish passwords from unsuspecting users.
In fact, XSS flaws are one of the most commonly encountered security flaws found on websites.
So imagine the perfect storm of potential XSS attack vectors being secretly embedded deep within many of the world’s websites, run on the phenomenally popular WordPress platform… all without the knowledge of the site’s administrators who have placed their trust in legitimate third-party WordPress plugins which had misused two functions: add_query_arg() and remove_query_arg().
The risk was highlighted by Joost de Valk, the developer of two popular affected plugins – WordPress SEO by Yoast and Google Analytics by Yoast – used by millions of websites around the world.
As the Dutch plugin developer explains in his blog post on the subject, the problem was caused by following WordPress’s official developer’s documentation:
“I, Joost, created the particular problem myself and was wondering how that had gotten by me, when I figured out that both the Codex and the developer documentation on WordPress.org for these functions were missing the fact that you had to escape their output. In fact, the examples in them when copied would create exploitable code straight away. I spoke to Samuel, mostly known in the WordPress community as Otto42, and he fixed the codex. A day later, the developer docs were amended as well.”
Of course, if a professional plugin development company like Yoast could put users at risk of an XSS vulnerability by simply following WordPress’s own coding examples, chances were that other plugins were also likely to be carrying the same programming bug.
A team of developers and the WordPress core security team co-ordinated their efforts, combing through the top tiers of the WordPress repository in an attempt to find other affected plugins, and reach out to developers to get the problem fixed.
As Sucuri notes, some very high profile plugins were suffering from the flaw and could have put users at risk.
Affected plugins include:
- Jetpack
- WordPress SEO
- Google Analytics by Yoast
- All In one SEO
- Gravity Forms
- Multiple Plugins from Easy Digital Downloads
- UpdraftPlus
- WP-E-Commerce
- WPTouch
- Download Monitor
- Related Posts for WordPress
- My Calendar
- P3 Profiler
- Give
- Multiple iThemes products including Builder and Exchange
- Broken-Link-Checker
- Ninja Forms
Unfortunately, it hasn’t been possible to check every single plugin in the WordPress repository as there are almost 40,000 of them. Only about the most popular 1% or so have been checked, so it is very possible that there are other plugins which also contain the same vulnerability, and they might be running on your website.
So, what can you do?
Well, first things first. If you administer your WordPress website, update your plugins. All of the plugins listed above have been updated since the vulnerability was made public in a co-ordinated disclosure yesterday.
Any out-of-date plugins can be updated by visiting your wp-admin dashboard inside WordPress.
Furthermore, ask yourself what you are doing to harden your website and WordPress installation? For instance, are you restricting access to your website’s admin interface to specific IP addresses? Are you in the habit of always being logged in to your website as an administrator, or do you only do that when you need admin rights?
Have you checked out what plugins and themes you have installed on your website, and removed any cruft that is no longer required?
Have you put web application firewalls and intrusion prevention solutions in place to reduce the chances of an attack that attempts to exploit a cross-site scripting flaw?
Patching is obviously sensible and should be undertaken at the earliest opportunity, but never forget that additional layers of protection can go beyond patches – and perhaps be proactive in defending your systems from abuse during the time when no official fixes are available.
Clearly mistakes have been made which allowed these vulnerabilities to filter into WordPress plugins, but we can at least feel relieved that action has been taken responsibly and rapidly – at least in the case of those most widely-used plugins.
They’ve done their bit. Now it’s your turn to do yours.
And, importantly, if you’re a WordPress plugin developer, make sure you read the latest technical chatter about the issue – including an update to their developer documentation to fix any ambiguity in its wording.
This article originally appeared on the Optimal Security blog.
