ヘッダーの値に含まれるXSSについて

Question

脆弱性の修正方針に関する質問です。

HTTP ヘッダーの値がレスポンスに出力され、それがエスケープされていないことでXSSの脆弱性が出た場合、それはパラメーターの値のエスケープ不足によりXSSが出た場合より危険度(CVSSの値)は低いといえ、修正の緊急度を下げる理由になるでしょうか？

反射型XSSは多くの場合、ユーザがフィッシングサイトに誘導され、そこからスクリプト等を含んだリクエストを投げてしまうことで攻撃が成り立ちます。パラメーターに脆弱性がある場合はフィッシングサイトがリクエストのパラメータにスクリプトを入れることは容易ですが、ヘッダーの場合はFormによるリクエストの送信ではヘッダーの値にスクリプトを入れることはできませんし、JSによる送信では多くの制限がかかると思っています。
JSによるヘッダー付与しようとした場合、
・クロスドメインリクエストによる制限
・攻撃対象ドメインに対応するCookieをつけてられない
・RefererやHOSTの値は変更できない
等

現実的には、ヘッダーの値にXSSの脆弱性があっても攻撃シナリオが成り立たない場合が多いと思います。(もちろん、HTTPヘッダーインジェクションや古いブラウザ等の別の要因があれば異なりますが)
そのため「ヘッダーの値を変更して攻撃するのは難しいから、脆弱性を修正をしない/後回しにする」という考え方をする理由になるのかが気になります。
また、もし現実的に起こり得る(フィッシングサイト経由でヘッダーの値にスクリプトを入れるような)攻撃シナリオをご存じでしたら教えてください。

Answer 1

HTTP ヘッダーの値がレスポンスに出力され、それがエスケープされていないことでXSSの脆弱性が出た場合、それはパラメーターの値のエスケープ不足によりXSSが出た場合より危険度(CVSSの値)は低いといえ、修正の緊急度を下げる理由になるでしょうか？

理由にはなるでしょうが、修正の緊急度というものは法律等で決まっているものではなく、その現場のポリシーによるものですから、ポリシー次第ということになります。CVSS値で緊急度を決めているのであれば、現実問題として緊急度を下げる運用になるでしょう。ただし、本当にCVSS値を反映する運用にしているのかという疑問は残ります。

ただし、攻撃可能性の判断というものは、ベテランの専門家でもしばしば間違います。失礼ながら、質問文の記述にも間違いがいくつかあります。

JSによる送信では多くの制限がかかると思っています。

これ自体は正しく、その後の内容も局所的には間違いではありませんが、そもそもJS(XHR等)では反射型のXSSはできません。これについては、下記の動画を見ていただくのが良いと思います。

なぜPHPの「XSS」脆弱性CVE-2018-17082はXSS攻撃できないか - YouTube

もちろん、HTTPヘッダーインジェクションや古いブラウザ等の別の要因があれば異なりますが

HTTPヘッダインジェクションでは、HTTPリクエストヘッダを改変することはできません。

そのため「ヘッダーの値を変更して攻撃するのは難しいから、脆弱性を修正をしない/後回しにする」という考え方をする理由になるのかが気になります。

前述のように、そのように判断することは可能ですが、判断を間違える可能性が高いので一律に脆弱性を修正するというのも現実的な考え方です。

また、もし現実的に起こり得る(フィッシングサイト経由でヘッダーの値にスクリプトを入れるような)攻撃シナリオをご存じでしたら教えてください。

有名なところでは、RefererヘッダからのXSSは可能です。また、通信経路上に攻撃者がいるばあいは、CookieによるXSSも考慮する必要があります。

Comments

[yuikura]

回答ありがとうございます。
攻撃可能か否かで判断するのはリスクを伴うという点について理解しました。検出した場合は修正する方向で考えた方がよさそうですね。
また、HTTPヘッダインジェクションは大きく誤っていました....ご指摘ありがとうございます。