Cross-Site Scripting (XSS) in WordPress 4.8

Cross-site scripting or XSS for short is security vulnerability typically found in web applications. It is basically allowing an attacker to execute potentially malicious script code in the website visitor’s browser.

This vulnerability has been around for decades and it is has been still growing in the last few years. According to HackerOne XSS is still a major threat vector. With the continuous development of new web technologies, it is easier to migrate to this vulnerability.

Are you a WordPress developer?

Try WebARX 7-day free trial.

Try it free

About the Vulnerability in WordPress

A while back, WebARX security researcher Luka did research on WordPress 4.8 and he discovered that $file_description and $description from wp-admin/theme-editor.php are not filtering the name of the template allowing an attacker to execute an XSS attack. Here’s the full write-up of the vulnerability and how it was discovered.

$file_description = get_file_description( $filename );

You can see it’s getting file description, using “get_file_description” which is defined inside wp-admin/includes/file.php and it is getting template name from the file comment.

$file_description = get_file_description( $filename );

if ( $filename !== basename( $absolute_filename ) || $file_description !== $filename ) {$file_description .= '<br /><span class="nonessential">(' . $filename . ')</span>';

}

if ( $absolute_filename === $file ) {
$file_description = '<span class="highlight">' . $file_description . '</span>';

}

$previous_file_type = $file_type;
?>
<li><a href="theme-editor.php?file=<?php echo urlencode( $filename ) ?>&theme=
<?php echo urlencode( $stylesheet ) ?>"><?php echo $file_description; ?></a></li>
<?php
endforeach;
?>

From this code, we can see that $file_description = get_file_description( $filename ); is getting declared and later on under <li><a> tags template name is printed on the page ...<?php echo $file_description; ?></a></li>

$file_description variable should be filtered before displayed to the user. For example, using htmlspecialchars() function.

If the victim clicks on the file that contains XSS payload, XSS will be executed because $description = get_file_description( $relative_file ); is displaying name of the active file the person is editing.

So what if we insert XSS payload after “Template Name:”

Jackpot!

Steps to replicate

1. Go to Appearance > Editor
2. Select file you want to edit (don’t select files that already have a name – Archives, Theme Footer for example). Luka used “back-compat.php”
3. At the very top of the file add the following comment: /* Template Name: <script>confirm(document.cookie);</script> */
4. Click on Update File.
5. XSS Popup will be prompted.

Most of the popular and modern web development frameworks are using template engines that come with XSS protection out-of-the-box. They also have options for developers to allow execution of script code and that is where XSS occurs. WordPress is a nice and useful CMS without any real competitor on the market.

This vulnerability was reported to the WordPress team by following responsible disclosure policy. It is patched in version 4.8.2.

There are four simple steps for beginners when hunting for XSS:

1. Before doing any tests make sure you understand how it works and what features it has.
2. Focus on one component at the time, example: WordPress templates
3. Find out where dynamic parts come from (can you interact with them?) example: Template name
4. Input payloads, check if they are being rendered in the actual code.

When hunting for bugs in open source projects, understanding its code is a big plus. Having messy code is also beneficial for security researchers. If It’s hard to read, it must be hard to maintain.

Is your website protected against such vulnerabilities?

Check out now