How to exploit HTTP header XSS vulnerability?

Question

Let's say that a page is just printing the value of the HTTP 'referer' header with no escaping. So the page is vulnerable to an XSS attack, i.e. an attacker can craft a GET request with a referer header containing something like <script>alert('xss');</script>.

But how can you actually use this to attack a target? How can the attacker make the target issue that specific request with that specific header?

Answer 1

Exploitation of xss at referrer header is almost like a traditional reflected xss, Just an additional point to make is "Attacker's website redirects to victim website and hence referrer header with required javascript will be appended to the victim website request".

Here One essential point that needs to be discussed is Why only with IE one can exploit this vulnerability why not with other browsers?

Traditional answer for this question is 'Chrome and firefox automatically encodes URL parameters and hence XSS is not possible..' But interesting thing here is when we have n number of bypasses for traditional xss bypasses. why can't we have bypasses for this scenario.

Yes.. We can bypass with following payload which is same way to bypass HTML validation in traditional payload.

http://evil.example.com/?alert(1)//cctixn1f .

Here the response could be something like this:

The link on the referring page seems to be wrong or outdated. Response End

If victim clicks on referring page, alert will be generated..

Bottomline: Not just only IE, XSS can be possible even in Mozilla and Firefox when referrer is being used as part of href tag..

Answer 2

This sounds like a standard reflected XSS attack.

In reflected XSS attacks, the attacker needs the victim to visit some site which in some way is under the attacker's control. Even if this is just a forum where an attacker can post a link in the hope somebody will follow it.

In the case of a reflected XSS attack with the referer header, then the attacker could redirect the user from the forum to a page on the attacker's domain.

e.g.

http://evil.example.com/?<script>alert(123)>

This page in turn redirects to the following target page in a way that preserves referer.

http://victim.example.org/vulnerable_xss_page.php

Because it is showing the referer header on this page without the proper escaping, http://evil.example.com/?<script>alert(123)> gets output within the HTML source, executing the alert. Note this works in Internet Explorer only.

Other browsers will automatically encode the URL rendering

%3cscript%3ealert%28123%29%3c/script%3e

instead which is safe.

Answer 3

I can think of a few different attacks, maybe there are more which then others will hopefully add. :)

If your XSS is just some header value reflected in the response unencoded, I would say that's less of a risk compared to stored. There may be factors to consider though. For example if it's a header that the browser adds and can be set in the browser (like the user agent), an attacker may get access to a client computer, change the user agent, and then let a normal user use the website, now with the attacker's javascript injected. Another example that comes to mind is a website may display the url that redirected you there (referer) - in this case the attacker only has to link to the vulnerable application from his carefully crafted url. These are kind of edge cases though.

If it's stored, that's more straightforward. Consider an application that logs user access with all request headers, and let's suppose there is an internal application for admins that they use to inspect logs. If this log viewer application is web based and vulnerable, any javascript from any request header could be run in the admin context. Obviously this is just one example, it doesn't need to be blind of course.

Cache poisoning may also help with exploiting a header XSS.

Another thing I can think of is browser plugins. Flash is less prevalent now (thankfully), but with different versions of Flash you could set different request headers on your requests. What exactly you can and cannot set is a mess and very confusing across Flash plugin versions.

So there are several attacks, and it is necessary to treat all headers as user input and encode them accordingly.