質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.90%

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

解決済

回答 1

投稿 編集

  • 評価
  • クリップ 2
  • VIEW 284

yuikura

score 12

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

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

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

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 1

checkベストアンサー

0

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

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

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

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

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

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

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/20 19:11 編集

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.90%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る