反射型XSS | Security Atlas

何が起きるか

反射型XSSは、攻撃者がURLの検索語などへ入れたコードを、サーバーが応答HTMLへそのまま組み込み、リンクを開いた利用者のブラウザで実行させる問題です。入力は保存を経ず、直後の応答へ反映されます。

説明用に、検索語を結果ページへ表示するサイトを考えます。攻撃者がHTMLのタグやJavaScriptを呼ぶイベント属性を検索語に入れたURLを作り、被害者に開かせます。サーバーが検索語を文字としてエスケープせずHTMLへ連結すると、ブラウザは応答内のタグや属性をページの構造として解析し、該当するイベントで攻撃者のコードを実行します。たとえば検索語に画像要素とonerror属性が入り、存在しない画像の読み込みが失敗すると、その属性に書かれたJavaScriptが動く構成です。この場合はページを開く動作に続いて画像エラーが起きるため、追加のクリックがなくても実行され得ます。

コードは対象サイトのページ内で動くため、同じページに表示済みの非公開メッセージをDOMの要素から読み、その内容を攻撃者のサーバーへ送信できれば、攻撃者が会話内容を取得できます。被害者がその情報を閲覧できることと外部送信できることが必要で、サーバーのOS上で命令を実行する攻撃とは区別します。

正常ならどう動くか

検索語をHTML本文へ表示するなら、サーバーのテンプレートが<や>などをHTMLの特殊な構造として解釈されない表記にして出力します。ブラウザは元の検索語を文字として見せ、検索語の中のタグを実行する要素として作りません。たとえば<b>をHTMLソース上の<b>へ変換して出力すると、ブラウザは<b>という文字を表示します。文字参照を読み取った結果を、新しいb要素として再び解析するわけではありません。

属性値、URL、JavaScriptへ入力を入れる場合は、それぞれ異なる記号に意味があります。たとえば表示するリンクのURLでは、文字のエンコードだけでjavascript:などを安全なリンクへ変えられるわけではありません。挿入先に合ったテンプレート機能と許可するURLスキームの制限を使います。これは入力をリンクのhref属性へ使う場合の話です。javascript:はリンクを開いたときにJavaScriptを評価するスキームなので、リンク先にはhttps:など用途に必要なスキームだけを許可します。

不備と攻撃が成立する流れ

攻撃者が検索語にHTMLのタグやイベント属性を含めた対象サイトのURLを作り、被害者へ開かせます。被害者のブラウザがそのURLでHTTPリクエストを送ると、サーバーは検索語を取得します。サーバーが検索語を文字としてエスケープせずHTMLへ連結すると、HTTPレスポンスに実行可能なHTMLが入ります。

被害者のブラウザは対象サイトから受け取ったHTMLを解析し、検索語に含まれるJavaScriptを実行します。この入力をページ内のコードとして採用する箇所がXSSです。実行場所は被害者のブラウザで、コードは対象サイトのオリジンとして動きます。

起こり得る被害と条件

情報取得の例では、実行されたコードが同じオリジンの非公開メッセージAPIへHTTPリクエストを送ります。同じオリジンへのfetchの既定設定なら、ブラウザが有効なログイン用CookieをそのリクエストのCookieヘッダーへ付けます。サーバーがCookie内のセッションIDから被害者を特定し、APIが本人向けの本文を返すと、コードが本文を読めます。その本文を攻撃者のサーバーへ送信できれば、攻撃者が他人の会話内容を入手します。

設定変更の例では、コードが被害者の登録メールアドレスを攻撃者のアドレスへ変更するリクエストを送ります。APIが被害者のログイン状態で変更を許可すれば、攻撃者は変更後の宛先に送られる通知を受け取るおそれがあります。追加の再認証が必要な操作は、その条件も満たさなければ実行できません。

偽画面の例では、コードがページのDOMを書き換えて再ログインを装う入力欄を表示します。被害者が入力したパスワードをコードが読み、外部へ送信できれば、攻撃者はその値を入手します。全ての例で、まず攻撃用の入力を含むURLなどを被害者に開かせ、コードの実行を成立させる必要があります。

防ぎ方と、防げる理由

検索語を出力するテンプレートの標準機能を使い、HTML本文・属性など実際の挿入先に合う方法でエンコードします。利用者の文字列をJavaScriptコードへ直接埋め込まず、URLを表示・採用する場合は許可するスキームも限定します。検索語がページのコードや構造を変えず、表示する値として扱われるようにするためです。

よくある誤解

保存されないXSSでも、管理者のブラウザで実行されれば、管理者が許可された機能を不正に使われるおそれがあります。CSPはコードの実行や読み込みを制限する追加策ですが、出力処理の不備そのものを修正する対策と組み合わせる必要があります。

実装の確認点

検索語、エラー、戻り先URLなどが応答へ入る箇所を追います。標準エスケープを無効にする処理や、HTML属性・URL・JavaScriptへ入る値を、実際の表示先の意味に合わせて確認します。

出典・確認範囲

[1] Web Security Academy: 反射型XSSPortSwigger / 確認日 2026-11-01