When you say that it can be “can be manipulated by the visitor”, were you actually able to cause this to be exploitable?
We were contacted by the person behind this claimed vulnerability a couple days ago and we asked if they were actually able to cause it to be exploitable, but haven’t gotten a response. In our looking into this it looks like it might not be possible to do that, since it looks like the value of HTTP_HOST would not be able to be manipulated in a web browser.
Apparently, as far as I understand from this:
Version: 4.0.8 (latest)
The plugin contains a Paypal donate button that is echoing the global variable HTTP_HOST, which can be manipulated by the visitor.
Vulnerable Code:
sitemap-ui.php L1310
echo ‘http://’ . $_SERVER[‘HTTP_HOST’]…
it is your Paypal donation button that causes issues.
Won’t it be wise to just remove that as a first step and then see what really happens with this vulnerability?
-
This reply was modified 7 years ago by John.
-
This reply was modified 7 years ago by John.
The vector for a reflected XSS via the Host:
header is small, if it is even possible.
It relies on;
1. The web server being configured to serve the WordPress site as the default (i.e. with an unrecognised Host:
header, without redirecting.
2. The victim’s browser making a request with a malformed Host:
header.
The latter is extremely difficult for an attacker to pull off as it cannot be done with a link alone. It may not even be possible in most/all browsers.
It’s unlikely this vulnerability is currently viable, but that’s not to see it couldn’t be in future. Bugs have existed in the past that have allowed for Host:
header manipulation, ref:
http://security.stackexchange.com/a/46758/122327
http://www.securityfocus.com/archive/1/441014/30/0/threaded
Given that it’s also extremely easy to mitigate, i.e.
htmlspecialchars($_SERVER['HTTP_HOST'], ENT_QUOTES, 'UTF-8');
In my opinion it seems like it would be better to err on the side caution and sanitise.
-
This reply was modified 7 years ago by tommarshall. Reason: Fix formatting
-
This reply was modified 7 years ago by tommarshall.
I agree with the sentiment that “people need to be more responsible when it comes to spreading vulnerability claims”, however I wasn’t the one who raised the original vulnerability report, nor was I responsible for it being accepted onto the WPScan Vulnerability Database.
I raised the issue here as I have a number of WordPress sites using this plugin which are currently being flagged as insecure by my automated monitoring as there’s unpatched vulnerability on https://wpvulndb.com. That requires action.
Given that proving a vector does not exist for this would require a lot of work and the preventative fix is trivial, raising the ticket on the project felt like the appropriate action.
I’ve come here for this issue and I am confused about the discussion. Vulnerable or not? Can something be done?
@maggieymae
There hasn’t been any evidence that the plugin is vulnerable provided so far, only that a potential vulnerability exists.
The developer can easily fix the issue. We have sent them an email to let them know about this discussion and the issue.
@tommarshall
You are spreading the claim though and you didn’t provide any disclaimer as to the reliability of the claim when doing so originally. Raising the issue is fine; it is how you raised it that is the issue.
The WPScan Vulnerability Database doesn’t verify vulnerabilities before including them in their data, so the real issue is with services and people spreading their information without proper warning about that and other known reliability issues (including them incorrectly marking vulnerabilities as being fixed). If the monitoring you are using doesn’t do that you should take that up with them and or get your data from a source that actually checks claimed vulnerabilities before adding them to their data (full disclosure: we provide just such a service).
Bump.
Would love to read some words from the plugin author about this topic.