HTTP・HTML・DOM・JavaScriptと入力検証・出力時エスケープ

Webアプリのプロフィール名に危険な文字列が登録されたとき、どの段階でただの文字列が実行可能なコードになるのでしょうか。架空のhttps://portal.exampleのプロフィール画面を使い、HTTPの往復、サーバの処理、ブラウザのHTML解析、DOM更新、JavaScript実行を順に追います。

科目B（午後）では『入力を検証する』と『出力をエスケープする』を混同せず、どの値が誰の支配下にあり、どの構文へ挿入されるか答えます。HTTP・HTML・DOM・JavaScriptの境界を知ると、XSSだけでなくログや構成図の読解も容易になります。ドメイン、ユーザ、ログ、コード断片は教材用の架空例です。

1. Web処理を構成する用語

2. HTTPの一往復から画面表示まで

利用者aliceが表示名を登録します。ブラウザはCookieでセッションを送り、サーバは認証・認可を確認したうえで本文を受け取ります。次のHTTP/1.1表示は理解用の例で、HTTP/2やHTTP/3ではワイヤ上の表現が異なります。

POST /api/profile HTTP/1.1
Host: portal.example
Cookie: session=<省略>
Content-Type: application/json

{"displayName":"<img src=x onerror=...>"}

HTTP/1.1 200 OK
Content-Type: application/json

{"result":"saved"}

displayNameは利用者が支配する値です。サーバが登録に成功しても、まだブラウザで実行されたわけではありません。危険になるのは、後続のGET /profileでその値をHTML又は実行されるDOM操作へ安全な変換なしに入れたときです。ログにこの文字列があることも、ただちにXSS成立を示しません。

ブラウザは応答ヘッダと本文を受け取り、HTMLとして解析してDOMを作ります。その後、ページに含まれるスクリプトがDOMを更新する場合があります。サーバ側の入力検証と、HTML生成時・DOM更新時の扱いを別々に調べます。

2-1. リクエストとレスポンスのフィールド

3. HTML文字列、DOM、JavaScript実行を分ける

サーバ応答にdisplayNameをHTMLテキストとして入れる場合、値中の小なり記号などをHTMLの構文と解釈させないよう符号化します。ここでの例では、表示したい文字列そのものは変更せず、ブラウザがテキストノードとして読む形にします。

<!-- 危険: 信頼できない値をHTML構文へ直接連結 -->
<div class="name"><img src=x onerror=...></div>

<!-- HTMLテキストとして安全に表す例 -->
<div class="name">&lt;img src=x onerror=...&gt;</div>

// JSONで受け取った値をDOMの文字列として入れる例
nameElement.textContent = profile.displayName;

// 値をHTMLとして解析させるため危険になり得る例
nameElement.innerHTML = profile.displayName;

上のonerror=...は攻撃が成立する位置を示す省略表記です。実際のブラウザ挙動は要素、CSP、サニタイズなどにも依存します。重要なのは、最初の例では文字列がHTML要素・属性として解釈され、後二つでは同じ値がテキストになるかHTMLになるかがAPIで変わることです。

ブラウザ側スクリプトは通常、そのページのオリジンの権限でDOMや同一オリジンのAPIを利用できます。サーバ側スクリプトはブラウザDOMを直接持たず、サーバのDB資格情報や内部ネットワークへアクセスし得ます。『JavaScriptが動いた』だけでは、実行場所と利用できた資産を特定できません。

3-1. サーバ応答と現在のDOMはなぜ違うか

GET /profileのレスポンス本文には静的なHTMLがあっても、ブラウザは解析中にノードの木を作り、後からスクリプトがノードを追加・削除できます。開発者ツールのElementsで見る現在のDOMと、Networkで見る元のHTTPレスポンスを両方確認します。前者だけではサーバが送った文字列を、後者だけでは後続のDOM操作を確定できません。

HTTPレスポンスがJSONでも、ブラウザがその文字列をinnerHTMLへ渡せばHTMLとして再解釈されます。逆にHTMLに埋め込む値を正しく符号化しても、後で別のスクリプトが同じ値を危険なAPIへ渡せば再び危険になります。出所から最終的な挿入先まで追う必要があります。

3-2. scriptの読み込み順は実行場所と別

HTML中の通常のclassic scriptは解析中に実行され、defer付きclassic scriptは解析完了後に実行されます。asyncは取得完了の時点で実行されるため、DOMの準備順に依存するコードで注意が必要です。moduleも依存モジュールの取得と評価順を持ちます。いずれも通常はブラウザ側の実行で、サーバ側JavaScriptに変わるわけではありません。

4. 入力検証は何を判断し、何を判断しないか

POST /api/profileではdisplayNameが文字列か、最大長、制御文字、業務上の禁止値をサーバで検査します。ブラウザ側のフォーム検証は操作性の助けになりますが、HTTP要求を直接送る攻撃者が迂回できるため、サーバ側の判断を省けません。

たとえば<を禁止する入力規則でも、別のAPI、インポート機能、既存DB行を通じて危険な文字列が画面へ届く可能性があります。逆に記号を許す要件があるなら、記号を安全なテキストとして表示できる実装が必要です。入力検証は不正なデータや業務操作を拒否し、出力時エスケープは構文解釈を制御します。

4-1. 変換の順序と二重エスケープ

表示名をDBへ保存する時点でHTMLエスケープ済み文字列へ置き換えると、同じ値をJSON、メール本文、CSVへ出すときに扱いが複雑になります。原則として保存するのは検証済みの元データとし、表示する場所で必要な構文変換を行います。安全に文字を許すことと、どこへ出しても同じ変換で済むことは別です。

たとえばDBに&lt;という5文字を保存した上でテンプレートもHTMLエスケープすると、画面には&amp;lt;のように見える二重エスケープが起き得ます。反対に、表示が崩れるからとテンプレートの自動エスケープを全体で切ると、別の保存値からXSSが起き得ます。入力値、保存値、出力結果をそれぞれ記録して調べます。

サーバでの入力検証を通った値でも、DB移行や管理画面から取り込まれた値は同じ検証を受けていないかもしれません。出力箇所の安全性を『過去に入力検証したはず』という前提に依存させないことが、保存型XSSに対する重要な設計です。

5. 架空ログで実行段階を切り分ける

以下は架空の一連のログです。時刻はUTCで、値を読みやすく短縮しています。request_idは説明用に同じ要求を結ぶIDです。ブラウザのDOM状態はサーバログに自動では残りません。

09:00:00 app request_id=A1 method=POST path=/api/profile
  user=alice validation=pass saved_name=<img...>
09:01:00 app request_id=A2 method=GET path=/profile
  user=alice status=200 template=profile-v2
09:01:01 browser trace=A2 dom_sink=innerHTML
  input_source=/api/profile display_name=<img...>
  effect=unexpected_event_handler

サーバ側では入力保存まで、ブラウザ側ではDOMへの挿入以降を追います。問題がサーバHTMLテンプレートにあるのか、フロントエンドのinnerHTMLにあるのかで修正箇所が異なります。HTTP 200やvalidation=passを『安全』の証拠にしません。

6. 攻撃条件と修正後の確認

攻撃者は表示名を書き込めること、被害者がその値を見ること、HTML又は危険なDOM APIへ値が到達することが必要です。入力欄に文字列を送っただけ、DBに保存しただけでは実行は確定しません。CSPは影響緩和に役立ちますが、脆弱なinnerHTMLを残す理由にはなりません。

1. 保存値の出所と使用箇所を洗い出し、サーバHTMLテンプレートとDOM操作の両方を確認する。

2. HTMLテキストならテンプレートのエスケープ又はtextContentへ直す。属性、URL、スクリプトへ置く箇所は各構文に合った処理へ変える。

3. 正常な日本語・記号入り表示名が表示でき、テスト用の危険な文字列が文字列として見えることを確認する。他の画面・管理UI・メールでも同じ保存値を試す。

4. 攻撃期間中の表示対象者、端末側挙動、外向き通信を調べ、必要ならセッションや資格情報の失効を判断する。

回復を問われた場合は、修正コードの配備だけで終えません。保存済み値の表示経路がすべて修正されたか、既存データを安全に扱えるか、被害者のセッションと不審な操作が残っていないかを確認します。

6-1. アプリの修正と防御層の役割

CSPは、許可するスクリプト元やインライン実行を制約する追加の防御です。ただし設定次第で効果は変わり、危険なHTMLを生成する実装自体を正す必要があります。外部スクリプトを許している場合、その提供元が侵害されたときの影響も考えます。

CookieのHttpOnlyはJavaScriptからのCookie読取りを制限しますが、XSSがあれば同一オリジンのAPIへ被害者として要求を送れる場合があります。『Cookieを盗めないから影響なし』と結論しません。出力時の安全な扱い、CSP、セッション保護、アプリの認可をそれぞれの位置で確認します。

7. 科目B（午後）の記述演習

演習1：200と実行段階

条件：GET /profileが200で返り、DBにdisplayNameが保存された。問い：この二つの事実だけでXSSを断定できるか。

解答：断定できない。レスポンス内の出力方法、DOM操作、ブラウザでの解釈・実行を確認する。誤答『保存されたので必ず実行』は保存と構文解釈を混同する。

演習2：入力検証と出力

条件：表示名は100文字以内なら任意の記号を許す。プロフィール画面で値をテキストとして表示したい。問い：主な修正位置を述べよ。

解答：サーバでは型・長さ・認可を検証し、HTML生成時はHTMLテキストとしてエスケープする。DOM更新ならtextContentを使う。誤答『<を全面禁止するしかない』は正当な記号表示と出力時の安全な扱いを無視する。

演習3：サーバ側とブラウザ側

条件：/api/profileはJSONで値を返し、画面のJavaScriptがinnerHTMLへ代入した。問い：修正すべき場所を述べよ。

解答：ブラウザ側のDOM挿入をtextContent等へ直す。サーバ側の入力検証も維持する。誤答『JSONで返しているから安全』は受信後にHTMLとして再解釈される点を見落とす。

演習4：HTML属性への挿入

条件：表示名ではなく利用者指定URLをa要素のhrefに入れる。問い：HTMLテキスト用エスケープだけでよいか。

解答：足りない。属性として安全に挿入し、許可するURLスキームと宛先も確認する。誤答『&lt;へ変えればすべての文脈で安全』はURLの意味と属性の構文を無視する。

演習5：元HTMLとDOMの差

条件：Networkのレスポンスには表示名が正しく符号化されているが、画面上では不正な要素が増えた。問い：次に調べる場所を述べよ。

解答：ブラウザ側で表示名を再取得し、innerHTMLなどへ渡すスクリプトと、その値の出所を追う。誤答『レスポンスが安全だからDOMも安全』は後続のDOM更新を見落とす。

演習6：サーバとブラウザのJavaScript

条件：ログにJavaScriptの例外があり、DB資格情報へのアクセスが疑われる。問い：実行場所をどう切り分けるか。

解答：サーバのプロセスログとブラウザの開発者ツール・スタックを分け、例外がどちらで起きたか確認する。ブラウザ側スクリプトは通常サーバのDB資格情報を直接持たない。誤答『JavaScriptなので必ずブラウザ側』は言語と実行環境を混同する。

8. 一次資料

RFC 9110：HTTPメソッド・ヘッダ・ステータスの意味

WHATWG HTML Standard：script要素と実行順

WHATWG DOM Standard：文書のノード木

OWASP：Input Validation Cheat Sheet

OWASP：Cross Site Scripting Prevention Cheat Sheet