XSSとは

詳細な図解

XSSを読むときの前提

XSS（Cross-Site Scripting）は、Webページに不正なスクリプトを実行させる攻撃です。入力フォーム、コメント、管理画面、外部データ表示、ログビューア、HTMLメール表示などで確認します。

実務では、出力エスケープ、入力検証、HTML/属性/URL/JavaScript文脈、CSP、CookieのHttpOnly、SameSite、監査ログを合わせて見ます。

証跡には、対象URL、入力値、出力箇所、実行文脈、再現手順、ブラウザConsole、影響を受けるCookieや権限、修正方針を残します。

入力ではなく出力文脈を見る

XSS対策では、入力を単純に禁止するだけでは足りません。同じ文字列でも、HTML本文、属性値、URL、JavaScript文字列、Markdown変換後など、出力される文脈で必要なエスケープが変わります。

外部APIやCSV、ログ、問い合わせ本文など、利用者が直接入力していないデータも危険な表示元になります。信頼境界を越えた値は出力時に処理します。

• 値がどの文脈に出るか確認する。
• テンプレートの自動エスケープを確認する。
• 外部データ表示も対象にする。

Cookie窃取だけが被害ではない

XSSの被害はCookie窃取だけではありません。利用者の権限で画面操作を行う、CSRFトークンを読む、APIを呼ぶ、表示を改ざんする、管理者に偽の操作をさせるといった影響があります。

HttpOnlyはCookieの読み取りを減らしますが、ブラウザからの操作自体を止めるものではありません。権限、監査ログ、再認証も確認します。

• 影響を受ける権限を確認する。
• HttpOnlyやSameSiteを確認する。
• 重要操作の再認証を確認する。

CSPは被害軽減として扱う

CSPはXSSの被害軽減に有効ですが、出力エスケープの代替ではありません。unsafe-inlineが残っている場合や広いscript-srcを許可している場合、効果は弱くなります。

Report-Onlyで違反を集め、nonceやhashを使えるかを確認します。攻撃の根本修正と、CSPによる防御層を分けて説明します。

• CSPのscript-srcを確認する。
• unsafe-inlineの理由を確認する。
• 根本修正と緩和策を分ける。

変更証跡と引き継ぎ

XSS対応では、再現入力、出力箇所、影響権限、修正内容、追加したテスト、CSPやCookie属性の補強を残します。脆弱性対応は再発防止のため、表示パターン単位で記録します。

引き継ぎでは、アプリ担当、セキュリティ担当、QA担当、関連語としてCSP、Cookie、HttpOnly、入力検証を残すと確認しやすくなります。

• 再現手順と修正後の確認を残す。
• 同じ表示部品の横展開を確認する。
• 脆弱性管理票へ影響範囲を記録する。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能