ページがHTTPのrefererヘッダーの値をエスケープしないで印刷しているとします。したがって、このページはXSS攻撃に対して脆弱です。つまり、攻撃者は<script>alert('xss');</script>のようなものを含むリファラーヘッダでGETリクエストを作成できます。HTTPヘッダーXSSの脆弱性を悪用するには？
しかし、これを実際にどのようにターゲットを攻撃するために使用できますか？どのようにして攻撃者は、特定のヘッダーで特定の要求をターゲットに発行させることができますか？
これは標準reflected XSS attackのようです。
反射XSS攻撃では、攻撃者は何らかの方法で攻撃者の制御下にあるサイトを訪問する必要があります。これは単に攻撃者が誰かがそれに従うことを望むようにリンクを投稿できるフォーラムであるとしても。
refererヘッダーを使用したXSS攻撃の場合、攻撃者はフォーラムからユーザーを攻撃者のドメインのページにリダイレクトできます。
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でのみ機能します。
他のブラウザは自動的に安全である代わりに
%3cscript%3ealert%28123%29%3c/script%3e
をレンダリングするURLをエンコードします。
私はいくつかの異なる攻撃を考えることができます。多分、他の人がうまく追加してくれるものがあります。 :)
あなたのXSSがレスポンスにエンコードされていないレスポンスに反映されているだけのヘッダー値であれば、それはストアされたものと比較して危険性は低いと言えます。しかし考慮する要因があるかもしれません。たとえば、ブラウザが追加してブラウザに設定できるヘッダー（ユーザーエージェントのような）の場合、攻撃者はクライアントコンピュータにアクセスし、ユーザーエージェントを変更し、通常のユーザーにWebサイトを使用させる可能性があります攻撃者のJavaScriptが注入されています。もう1つの例としては、WebサイトにリダイレクトされたURL（リファラー）が表示されることがあります。この場合、攻撃者は注意深く作成されたURLから脆弱なアプリケーションにリンクするだけです。これらは端切れの一種です。
保存されている場合は、それがより簡単です。すべてのリクエストヘッダーでユーザーアクセスを記録するアプリケーションを考えてみましょう。そして、ログを検査するために使用する管理者用の内部アプリケーションがあるとしましょう。このログビューアアプリケーションがWebベースであり、脆弱な場合、任意のリクエストヘッダーからのjavascriptは管理コンテキストで実行できます。明らかにこれはほんの一例に過ぎず、もちろん盲目的である必要はありません。
Cache poisoningも、ヘッダーXSSの利用に役立つ場合があります。
私が考えることのできるもう一つのことは、ブラウザプラグインです。 Flashはあまり普及していません（ありがたいことですが）Flashのバージョンが異なると、リクエストに異なるリクエストヘッダーを設定することができます。 What exactly you can and cannot setは混乱し、Flashプラグインのバージョン間で非常に混乱します。
したがって、いくつかの攻撃があり、すべてのヘッダーをユーザー入力として処理し、それに応じてエンコードする必要があります。