Support » Plugin: Google XML Sitemaps » Authenticated Reflected XSS (via HOST header) in 4.0.8

Viewing 9 replies - 1 through 9 (of 9 total)
  • That’s bad. Deleted!

    Plugin Vulnerabilities

    (@pluginvulnerabilities)

    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 1 month, 4 weeks ago by John.
    • This reply was modified 1 month, 4 weeks 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 1 month, 3 weeks ago by tommarshall. Reason: Fix formatting
    • This reply was modified 1 month, 3 weeks ago by tommarshall.
    Plugin Vulnerabilities

    (@pluginvulnerabilities)

    If it isn’t viable then it isn’t a vulnerability. Calling it a potential vulnerability would probably be an accurate way to describe it.

    No one said that the value shouldn’t be escaped, but when something like this is over inflated it leads to things happening like the person above who unnecessarily deleted the plugin and gave it a one star review on the basis that it has a security vulnerability, which there isn’t evidence of at this time.

    People need to be more responsible when it comes to spreading vulnerability claims, as too often the original claims are inaccurate or outright false.

    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?

    Plugin Vulnerabilities

    (@pluginvulnerabilities)

    @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.

Viewing 9 replies - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.