JSONPという「呪い」を解く：コールバック関数検証の不備が招くXSSの深淵
現場でレガシーシステムの延命保守をしていると、時折出会うのが「JSONP」という亡霊だ。CORS（Cross-Origin Resource Sharing）が標準化される前、ドメインの壁を超えてデータをやり取りするために重宝されたこの手法だが、現代のセキュリティ基準で見れば、それは「自分から脆弱性を掘って公開している」に等しい。
特に、コールバック関数名の検証を怠ったJSONP APIは、攻撃者にとって格好の踏み台だ。今日は、なぜこれが危険なのか、そしてどう防御すべきかを、実務者の視点で深掘りしよう。
—
1. なぜJSONPのコールバックは「XSSの温床」になるのか
JSONPの仕組みは単純だ。サーバーはクライアントから渡された callback というパラメータ値をそのままレスポンスの先頭に埋め込み、JSコードとして実行させる。
// 正常なレスポンス例: callback=handleData
handleData({“id”: 1, “status”: “ok”});
ここでの最大の過ちは、「サーバー側が、この callback パラメータを単なる文字列として扱い、中身を一切検証しないこと」だ。
攻撃者は、ここを alert(document.cookie) や、任意の外部スクリプトを読み込むコードにすり替える。これが反射型XSSの典型的な攻撃ベクトルになる。
攻撃者視点のPoC（概念実証）
攻撃者は、以下のような罠URLをユーザーに踏ませるだけでいい。
https://api.example.com/data?callback=
これを受けたサーバーが、エスケープせずにレスポンスを返せば、ユーザーのブラウザ上で攻撃者のスクリプトが「APIの信頼されたドメインから送られてきたコード」として実行されてしまう。これがどれほど恐ろしいか、セキュリティを語る上で説明するまでもないだろう。
—
2. セキュアな実装：PHPによる厳密なバリデーション
JSONPを使い続ける必要がある場合、最低限の防衛線は「コールバック名のホワイトリスト制」だ。正規表現を用いて、識別子として許容される文字以外を徹底的に排除する。
以下は、実務で使えるセキュアなバリデーションの実装例だ。
‘Invalid callback name’]);
exit;
}
// 2. MIMEタイプを正しく設定（XSSを誘発するHTML解釈を防ぐ）
header(‘Content-Type: application/javascript; charset=utf-8’);
// 3. データ生成
$data = json_encode([‘id’ => 123, ‘message’ => ‘Hello World’]);
// 4. 出力
echo sprintf(“%s(%s);”, $callback, $data);
?>
ポイント:
application/jsonではなくapplication/javascriptを指定することで、ブラウザ側の誤解釈を減らす。preg_matchで[a-zA-Z0-9_]+に絞ることで、<や>、(などの特殊文字を一切弾く設計にしている。
---
3. 次世代の防御：CSPによるブラウザレベルの封じ込め
コードの修正はもちろん重要だが、多層防御の観点では「ブラウザのガード」も併用すべきだ。Content-Security-Policy (CSP) を設定し、信頼できないインラインスクリプトの実行を阻止する。
Nginxで設定する場合の例を挙げる。
Nginxの設定例
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com;";
もしレガシーな理由でどうしてもJSONPが外せない場合でも、CSPを厳格に設定しておけば、万が一コード側に脆弱性が残っていても、攻撃者が仕込んだ外部スクリプトの実行をブロックできる可能性が高まる。
---
4. チーフエンジニアからの提言：JSONPを廃止せよ
ここまで実装ガイドを書いておいてなんだが、「JSONPは今すぐ廃止する」のが、最も堅牢なセキュリティ対策だ。
2024年の今、CORSを正しく設定したREST APIを使わない理由はない。JSONPは「古き良き時代」の遺物であり、メンテナンスのコストとセキュリティリスクを天秤にかければ、即座に捨て去るべき負債である。
- リファクタリングの第一歩: フロントエンドの呼び出しを
fetch()に変更し、バックエンドのヘッダーにAccess-Control-Allow-Originを追加せよ。 - インシデントハンドリングの知見: もし現在JSONPを使っているなら、直ちにWAFで
callbackパラメータに特殊文字が含まれていないかログを分析してほしい。すでに攻撃の予兆があるかもしれない。
セキュリティとは、穴を塞ぐことだけではない。「脆弱な仕組みそのものを、より安全な設計に置き換える」ことこそが、真のエンジニアリングだ。今日からでも、その「亡霊」をコードベースから追い出す計画を立ててほしい。それが、君のシステムを守る唯一の道だ。
コメント