In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Reflected Cross-Site Scripting (XSS) Vulnerability in Google Doc Embedder

Earlier today we mentioned that there are a number of issues with the Plugin Directory’s reviewing plugins before they return to the directory, which is one of many issues that seems like it could be improved if the people behind that were more open about what they are doing and able incorporate outside suggestions for improvement. Another area that seems like it might be improvable based on what is describe below, is deciding when to remove plugins.

The plugin Google Doc Embedder was recently removed from the Plugin Directory and the maintainer of the plugin wrote this about why that occurred:

There was a security alert whereby it appeared a cross-site scripting attack could have been carried out. This was inside a file that was no longer in use so it has just been removed from a new version 2.6.3 that should be released shortly.

Looking at the changes made to the plugin the file referred there was /js/tb-newwin.php. If you were to just look quickly at the code there is what appear to be a reflected cross-site scripting (XSS) vulnerability in it.

First the value of a couple of GET inputs are set to variables without being sanitized:

16
17
18
19

if ( isset( $_GET['url'] ) ) {
	$url = $_GET['url'];
	if ( isset( $_GET['hl'] ) ) {
		$lang = $_GET['hl'];

And then those variable are output without being escaped:

96

thisIFrame = "https://docs.google.com/viewer?url=" + "<!--?php echo $url; ?-->*chrome=true&hl=<!--?php echo $lang; ?-->";

If you were to test out exploiting this, which seems to be a step that is too often not done when checking on possible vulnerabilities, you would find that it doesn’t work. The reason for that is that the file set the content-type to “text/javascript”:

27

header("Content-type: text/javascript");

That would prevent JavaScript code from running. If a web browser could be tricked into believing that the page being served was actually a different content type than what is specified JavaScript code could run. That seems to have been more of a possibility with some older versions of web browsers. Since the page would contain a fair amount of content other than what comes from the reflected cross-site scripting (XSS), it might not be possible in that situation. So while it was good to resolve this, it seems questionable to have removed the plugin for it.