XSSの試験問題への適用
掲示板、検索結果、URL由来のDOM更新を例に、何を文字として扱い、どの表示経路を修正するかを判断します。基本の仕組みを確認し、独立した事例問題で対策を選びます。
この単元で学ぶこと
- 入力が命令として解釈される原因を説明する
- 処理する場所に合う根本対策を選ぶ
- 補助対策の効果と限界を区別する
- 事例から修正と確認の手順を組み立てる
本文解説
検索結果の表示を直す 検索語をそのまま応答HTMLへ入れる画面では、入力をどこに表示するかをまず確認します。通常のHTML本文へ文字として出すなら、テンプレートの適切なエスケープを使います。検索語を削除して何も表示しないことが目的ではなく、必要な文字をコードとして解釈させずに示すことが目的です。
textContentで結果を予測する 通常のdivへ文字列 <b>合格</b> をtextContentで設定すると、山括弧やbも文字として見えます。innerHTMLならb要素が作られ、合格が装飾されます。入力にHTMLを許可しない掲示板では、文字表示用のAPIを選ぶことで不要なHTML解析を避けられます。
保存投稿と管理画面 投稿者が社内の認証済み利用者でも、投稿内容を無加工で信用しません。投稿一覧だけ修正しても、詳細画面や管理画面が同じ値を危険な形で出力していれば問題が残ります。修正前から保存されている値も含め、どの画面へ流れるかを確認します。
URL由来のDOM更新 URLのフラグメントをJavaScriptが読み、innerHTMLへ渡す例ではブラウザ側の処理を追います。フラグメントは通常サーバーへ送られないので、サーバーログに値がないことは安全の根拠になりません。入力元、加工、DOMへの設定先をつなぎ、文字として扱える箇所は安全なAPIへ変えます。
リンク先と文脈 利用者指定のリンク先では、属性の引用符を壊さない処理だけでなく、許可するURLスキーム等も検証します。またHTML本文で安全に表示できた文字列を、JavaScriptコードへ直接埋め込んでよいわけではありません。出力先が変わるたびに解釈規則を確認し、コードとデータを分けた受渡しを選びます。
装飾を残す設計 太字と箇条書きだけを許可するなら、保守されたサニタイザーで許可要素や属性を限定します。scriptという単語だけを削ってもイベント属性等を見落とし得ます。テンプレートの生HTML出力の例外を使う場合は、未処理の値がそこへ到達しないかも確認します。
補助機能を過大評価しない HttpOnlyでCookieを直接読めなくしても、ページ内容の改変などが防げるとは限りません。CSPはポリシーの内容と実際の適用を確認し、危険な出力の修正に重ねます。HTTPSで保護して運んだ内容もブラウザは解釈するため、通信の暗号化だけでXSSがなくなるとは考えません。
確認項目を作る 通常の文章、記号、既存投稿、URL由来の値について、一覧・詳細・管理画面・DOM更新で期待どおり文字表示されるかを確認します。HTML装飾を許可する部分は許可範囲と禁止範囲を分けて確認します。一画面で記号を安全に表示できたことを、全経路の安全の証明にしないようにします。
図解
重要ポイント
- XSSではブラウザ側の解釈と実行が問題になる。
- 文字表示には安全なAPIや文脈に合うエスケープを使う。
- HTMLを許可する場合は許可範囲を限定してサニタイズする。
間違えやすい点
- 一種類のエスケープを全ての出力文脈へ流用しない。
- HttpOnlyやCSPをXSSの根本対策の代わりにしない。
- 保存済み・社内・認証済みという理由で入力を信用しない。
用語解説
- XSS
- 信頼できない入力を介して、Webページ内で不正なスクリプト等を実行させる攻撃。
- 出力エスケープ
- 出力先で特別な意味を持つ文字を、文字として扱うために適した表現へ変える処理。
- サニタイズ
- 許可する内容の規則に従い、危険な要素や属性等を取り除くなどして安全化する処理。
- DOM
- ブラウザが文書の構造をプログラムから扱うための表現と仕組み。
関連教材
参考資料
教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。
確認問題の出題・採点や学習履歴の保存にはログインが必要です。