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.

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:

https://security.stackexchange.com/a/46758/122327
https://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 8 years ago by tommarshall. Reason: Fix formatting
• This reply was modified 8 years ago by tommarshall.

That’s great. Thanks for letting me know.

If we have future issues with the plugin would you like them to be raised here, or on GitHub issues?

Hi meissudeep,

Thanks for getting back to us. After further investigation we discovered that the two leading spaces were leaking from another plugin, which had two spaces before it’s opening <?php tag in it’s init file. So it’s not a bug in Idle User Logout per-se, but trimming the response before the comparison will definitely make it more robust.

I don’t know what your browser support is like, but it’s worth noting that string.trim() in an ES5 function and only available in IE 9 upwards, though it can be easily polyfilled: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/String/trim

Thanks,
Tom