如何利用HTTP头XSS漏洞？
比方说，一个页面只是打印HTTP'referer'头部的值而不会转义。所以这个页面很容易受到XSS攻击，即攻击者可以利用包含诸如<script>alert('xss');</script>之类的引用标头来制作GET请求。如何利用HTTP头XSS漏洞？
但是你怎么能用这个来攻击目标呢？攻击者如何利用该特定头文件针对特定请求提出目标问题？
这听起来像一个标准的reflected XSS attack。
在反映的XSS攻击中，攻击者需要受害者访问某个以某种方式受攻击者控制的站点。即使这只是一个攻击者可以发布链接的论坛，希望有人会遵循。
如果反映的XSS攻击与referer标头相冲突，则攻击者可以将用户从论坛重定向到攻击者域中的页面。
例如
http://evil.example.com/?<script>alert(123)>
本页反过来重定向到以下目标页面，保留referer。
http://victim.example.org/vulnerable_xss_page.php
由于是示出没有适当的转义此页面上的referer头，http://evil.example.com/?<script>alert(123)>获取HTML源内的输出，执行所述警告。注意这只适用于Internet Explorer。
其他浏览器会自动编码URL渲染
%3cscript%3ealert%28123%29%3c/script%3e
反而是安全的。
我可以想到一些不同的攻击，也许有更多的其他人会希望添加。 :)
如果您的XSS只是未经编码的响应中反映的某个标题值，那么我认为这与存储的风险相比要小一些。可能有些因素需要考虑。例如，如果它是浏览器添加的并且可以在浏览器中设置的标头（如用户代理），则攻击者可能访问客户端计算机，更改用户代理，然后让普通用户使用该网站与攻击者的JavaScript注入。另一个想到的例子是，网站可能会显示重定向到的URL（引用者） - 在这种情况下，攻击者只需链接到他精心设计的url中易受攻击的应用程序。尽管如此，这些都是一些边缘案例。
如果存储它，那就更简单了。考虑一个记录所有请求头的用户访问的应用程序，假设有一个内部应用程序供管理员用来检查日志。如果此日志查看器应用程序是基于Web的并且易受攻击，则可以在管理上下文中运行任何请求标头中的任何JavaScript。显然，这只是一个例子，当然不需要盲目。
Cache poisoning也可能有助于利用头XSS。
我能想到的另一件事是浏览器插件。 Flash现在不太流行（幸好），但使用不同版本的Flash，您可以在请求中设置不同的请求标头。 What exactly you can and cannot set在整个Flash插件版本中都很混乱。
所以有几个攻击，有必要把所有的头文件作为用户输入，并相应地对它们进行编码。