CAll Us: +1 888-999-8231 Submit Ticket

WordPress Users Should Update The Akismet Plugin To Avoid Cross-Site Scripting Vulnerability

StoryformWordPress site owners who use the Akismet comment spam filtering plugin should update to version 3.1.5 of the plugin as soon as possible. Older versions of the plugin are vulnerable to a cross-site scripting attack that could put WordPress sites and users at risk of compromise. Sites with automatic updates activated should already be running the patched version, but it is probably worthwhile to check that your site is running the most recent version.

Site owners who rely on manual upgrades should immediately install the update for Akismet that is available in their site’s WordPress dashboard.

Akismet is installed on WordPress sites by default, making it by far the most popular spam-fighting plugin available for WordPress, although just having the plugin installed doesn’t put your site at risk. The proof-of-concept provided by Sucuri — the attack’s discoverer — requires that Akismet is activated and that the “Convert emoticons…” setting is enabled.

Disabling the “Convert emoticons…” setting will prevent the attack working as described by Sucuri, but the company recommends that Akismet users update anyway, because there are probably other paths to achieve the same outcome.

Cross-site scripting attacks rely on incorrect sanitization of user input. In the paradigmatic case, a malicious user will enter JavaScript code into the comment box (or other user input element) of a site. Ordinarily, code entered in this way will be escaped and sanitized so there’s no way that it could run in a user’s browser. A cross-site scripting vulnerability is essentially a failure to render code harmless in this way.

When a user loads a page with an attacker’s code on it, it will be executed by their browser. If an admin user loads a page with a cross-site scripting attack on it, the site could be compromised because the JavaScript code has access to otherwise secure content like cookies.

Cross-site scripting attacks hinge on a security feature built into browsers called the same-origin policy. The same-origin policy prevents site A from accessing information from site B, but it allows any content from pages on site A to access information from site A — including authentication cookies and other sensitive data. Content from the same origin is trusted. If a cross-site scripting vulnerability allows an attacker’s code to run in a user’s browser, that code has the same permissions as legitimate content from the site — if the user has admin privileges, that can include sensitive information.

Although it might seem simple, sanitizing user input is fraught with complexity, which is why cross-site scripting attacks are the most commonly reported vulnerability on the web.

If you’re interested in the full details of the attack, take a look Sucuri’s blog post.

Source link

About the Author