Using Our Plugin Security Checker to Find a Reflected XSS Vulnerability Patchstack Claimed Was in a Plugin
We have been seeing a reoccurring issue recently where WordPress plugin developers are having users of the plugins being asked if they are going to fix vulnerabilities that a WordPress security,Patchstack, has claimed are in their plugins. The developers are responding, accurately, that Patchstack hasn’t provided any details on what the issue is supposed to be. That obviously makes it difficult to address things if there really is a vulnerability, or to otherwise refute the claim. A recent instance of that involved a claim of a reflected cross-site (XSS) in the plugin WP Bannerize Pro.
Here are the “details” Patchstack provided:
thiennv discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress WP Bannerize Pro Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has not been known to be fixed yet.
That is no help.
One of the tools we have in our toolbox in that situation is our Plugin Security Checker, which is a tool that can flag some instances of insecure code in WordPress plugins. For this plugin, it flagged code that pretty easily should be caught as possibly allowing reflected XSS:
What that shows is that user input is being set to a variable without being validated or sanitized, and then the variable is output without escaping. We then created a proof of concept to confirm that this was exploitable.
That could be resolved by restricting the value set to the variable to an integer, using esc_attr() to escape the value when output, or a combination of both.
We tried to email the developer about that, but it is unclear if their email system passed the message through to them.
Proof of Concept
The following proof of concept will cause any available cookies to be shown in an alert box, when logged in to WordPress as user that can access the Pages admin page. In Safari and other web browsers that provide XSS filtering this proof of concept will not work.
Replace “[path to WordPress]” with the location of WordPress.
http://[path to WordPress]/wp-admin/edit.php?post_type=page&paged=%22%3E%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E