It is a XSS vulnerability, but it's quite difficult to exploit: Take for example the following URL:
http://anything."><script>xss</script>.example.com/aa/bb
This URL will carry an XSS payload in Host parameter when navigated to, but:
- DNS would have to resolve this strange domain to the IP with vulnerable application (so unless the DNS is quite forgiving attacker would require DNS poisoning)
- The browser would have to skip encoding the hostname - usually the hostname is percent encoded by the browser (so
<script> becomes %3Cscript%3E). You could of course forge the request outside browser.
- Target server would have to process the request in the context of the vulnerable website, which is not that simple. For example - if this application is installed as a
VirtualHost in Apache, this Host header will not match any VirtualHost and will be processed by a fallback or first VirtualHost.
It would be much more dangerous if this XSS was stored and not reflected, because then you could skip the (1) DNS and (2) encoding requirements. You could just plant the payload by sending manual HTTP request outside the browser. This payload would be then visible for 'standard' browser-based visitors of the vulnerable site.
So, as a conclusion - this is a XSS vulnerability, but with low exploitation probability. Still, the application should fix it by escaping the Host header being displayed.
request.getHeader("Host")be faked? Essentially allowing the attacker to make the script sourcesrc="http://attackersdomain/XXX/xxx.js"? – s_hewitt Dec 20 '11 at 15:09