Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If the following is the code snippet, what would be your suggestions?

<script type="text/javascript" src="<%=request.getHeader("Host")%>/XXX/xxx.js"></script>    

Is this a clear example of XSS? If yes, what are the attack scenarios which can be used by an attacker?

share|improve this question
Is part of your question: can the value of request.getHeader("Host") be faked? Essentially allowing the attacker to make the script source src="http://attackersdomain/XXX/xxx.js"? – s_hewitt Dec 20 '11 at 15:09
@s_hewitt: yes, that should also be the part of the question. – p_upadhyay Dec 20 '11 at 18:09
Host header can result in stored XSS and not in reflective XSS (unless you are trying to XSS yourself). Server processing your request doesn't need to have the same hostname as the host you sent your request to. So you can a request to host a with host header set to host b. But in most scenarios you will only be affecting yourself and not anyone else unless developer have made a mess in the code and there is some persistence of host header which will somehow be used for some other users. – Sachin Kumar Apr 5 '13 at 11:50
up vote 8 down vote accepted

It is a XSS vulnerability, but it's quite difficult to exploit: Take for example the following URL:


This URL will carry an XSS payload in Host parameter when navigated to, but:

  1. 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)
  2. 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.
  3. 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.

share|improve this answer
Awesome.. Thanks for the detailed reply. – p_upadhyay Dec 20 '11 at 18:34
can the value of request.getHeader("Host") be faked? Essentially allowing the attacker to make the script source at src="attackersdomain/XXX/xxx.js";? – p_upadhyay Dec 20 '11 at 19:18
@p_upadhyay it could be easily faked outside the browser, but the application would have to accept such request (see point 3 of the answer). In browser - not likely, it would require fiddling with the DNS. – Krzysztof Kotowicz Dec 22 '11 at 0:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.