With WordPress being used by millions of worldwide websites, the XSS vulnerability is particularly notable as it is located within the WordPress core build.
For Incapsula web application firewall (WAF) customers the good news is that you’ve been protected from XSS prior to this WordPress upgrade. Our research team has verified that our WAF blocks attacks attempting to exploit the vulnerability.
User Data Exposed
- Hijack session cookies and gain access to user sessions and accounts
- Operate a browser keylogger, which sends user keystrokes to the attacker
- Turn the user into a temporary bot to help execute attacks, such as DDoS, on other sites
Escaping the input in a WAF, which involves removing and replacing control characters, sanitizes the content and attempts to execute code are either blocked or deleted.
What’s Changed in WordPress 4.4.1?
Prior to the patch, the following PHP code was executed whenever a WordPress theme didn’t exist:
$this->errors = new WP_Error( 'theme_not_found', sprintf( __( 'The theme directory "%s" does not exist.' ), $this->stylesheet ) );
The actions performed by the code can be broken down as follows:
$this->errorsis a formatted error sent to the client browser.
WP_Errorclass (a custom WordPress type) is created to display an HTML error message.
- The error name is set to
‘theme_not_found’, and the description is set using
sprintf(a PHP function that formats text).
sprintf replaces the %swith the name of the stylesheet used to display the error message.
Note that the
sprintf PHP function, like the C#
String.Format function, or similar functions in other programming languages, is used to embed a given string within another. The function, however, does not sanitize or validate either of those strings.
The WordPress 4.4.1 patch adds the
esc_html() function. As shown below, this escapes the strings sent to the client, thus preventing cross site scripting:
$this->errors = new WP_Error( 'theme_not_found', sprintf( __( 'The theme directory "%s" does not exist.' ),esc_html( $this->stylesheet ) ) );
The remaining error messages that were not properly escaped are shown below:
$this->errors = new WP_Error( 'theme_no_parent', sprintf( __( 'The parent theme is missing. Please install the "%s" parent theme.' ), ) );
$_child->errors = new WP_Error( 'theme_parent_invalid', sprintf( __( 'The "%s" theme is not a valid parent theme.' ), ) );
$this->errors = new WP_Error( 'theme_parent_invalid', sprintf( __( 'The "%s" theme is not a valid parent theme.' ), ) );
The screenshot below shows how such non-sanitized requests can be used to execute a simple payload that displays a client’s cookies on screen. The same method can also be used to compromise the website in any number of different ways, including posting private cookie information on a remote site.
In this specific case, the payload is executed via the following string:
Note that in order for this to work, the user has to be authenticated as an administrator of the WordPress system.
Flaws such as these exist in popular applications. It’s one reason why using a layered approach–with a WAF on top of the application layer validation–is crucial in securing your websites.