蓄積型XSSの恐怖：なぜあなたのDBは「時限爆弾」と化すのか
現場でインシデント対応をしていると、「XSSなんて今更でしょ？」という慢心した空気を感じることがある。だが、断言しよう。蓄積型（Stored）XSSを見逃しているシステムは、爆弾の導火線に火がついた状態で放置されているのと同じだ。
反射型XSSが「通りすがりの悪意」なら、蓄積型は「システムそのものへの汚染」だ。攻撃者はあなたのデータベースを自分の遊び場に変え、全ユーザーを自分の操り人形にする。今回は、この「見えない脅威」をどう根絶やしにするか、泥臭い実務の視点から解説する。
—
1. 蓄積型XSSのメカニズム：DB汚染の正体
蓄積型XSSの悪質さは、その「永続性」にある。攻撃者は悪意あるスクリプトを、プロフィール欄、コメント欄、あるいは管理画面のログに至るまで、あらゆる入力フィールドからDBへ投げ込む。
攻撃者の思考プロセス
1. 注入: {"name": ""} のようなペイロードを送信。
2. 汚染: アプリケーションがサニタイズせずDBに保存。
3. 拡散: 他のユーザー（または管理者）がそのページを閲覧した瞬間、ブラウザはDBから吐き出されたコードを「正当なコンテンツ」と勘違いして実行する。
これが恐ろしいのは、「攻撃者が一度ログインして保存さえすれば、あとは寝ている間も自動で被害が拡大する」という点だ。特権を持つ管理者のブラウザで実行されれば、セッションハイジャックによるシステム乗っ取りも時間の問題となる。
—
2. 「防衛の鉄則」：出力時に逃げ切る
よくある誤解は「入力時にエスケープ（htmlspecialcharsなど）すればいい」というものだ。これは罠だ。なぜなら、データはDBに保存された後、APIとして外部へ出したり、メール本文に使われたり、あるいは管理画面で見たりと、用途が多岐にわたるからだ。
「入力はバリデーション、出力はエスケープ」。これがセキュリティの黄金律だ。
実装サンプル：PHPでのセキュアな出力処理
PHPで現代的なWebアプリを組むなら、テンプレートエンジン（Twigなど）を使うのが正解だが、生のPHPで書く場合も以下の原則を徹底せよ。
/
function h($str) {
return htmlspecialchars($str, ENT_QUOTES, ‘UTF-8’);
}
// ビュー側（HTML出力）での適用
echo “
“;
?>
—
3. 現代の切り札：CSP（Content Security Policy）
コードレベルの修正だけでは、ゼロデイやヒューマンエラーを防ぎきれない。そこでインフラ層からの防御、CSPの出番だ。これは「信頼できるスクリプト以外は一切実行させない」というブラウザへの強力な命令だ。
NginxでのCSP設定例
Nginxの設定ファイル（nginx.conf）に以下のヘッダーを追加するだけで、インラインスクリプトの実行を無効化できる。
外部からのスクリプト実行を許可せず、自ドメインのものだけを許可する設定
add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’; object-src ‘none’; frame-ancestors ‘none’;”;
script-src 'self': 外部の悪意あるスクリプトをブロックする。object-src 'none': Flashなどの古いプラグインによる攻撃を封じる。
—
4. 現場のシニアが教える「盲点」
最後に、教科書には載っていない「現場の泥臭い教訓」を2つ授ける。
1. 管理画面を狙い撃て: 攻撃者は一般ユーザーよりも、管理者が見る「ユーザー一覧」や「お問い合わせログ」に執拗にXSSを仕掛ける。ここが突破されると、システム管理権限が奪われ、DBのバックアップすら盗まれる。管理画面の入力・出力には、一般ページ以上の厳格なエスケープとCSPを適用せよ。
2. JSONレスポンスの危険性: APIとしてJSONを返す際、Content-Type: application/json を指定し忘れると、ブラウザが勝手にHTMLとして解釈しようとし、JSON内のデータでXSSが発火することがある。ヘッダーの指定は「お作法」ではなく「命綱」だ。
まとめ：次にやるべきこと
今すぐ、あなたのシステムのDBを確認してほしい。不自然な
コメント