【テクニカル・上級編】JSONPのコールバック関数悪用によるXSS – アプリケーションセキュリティ & 安全な開発防御ガイド

JSONPという「レガシーの呪縛」：コールバック注入が招く境界防御の崩壊

現代のWebアーキテクチャにおいて、JSONP（JSON with Padding）は既に「負の遺産」として扱われるべき存在だ。しかし、レガシーなサードパーティAPIや、古いモバイルアプリとの互換性を維持するために、今なお死に体で運用されているエンドポイントは少なくない。

セキュリティアーキテクトとして断言するが、JSONPを放置することは、自ら「ブラウザの同一生成元ポリシー（SOP）を無効化するバックドア」を維持しているに等しい。本稿では、なぜJSONPがXSSの温床となり、それをいかにして現代的なCORSアーキテクチャへと昇華させるべきか、その本質を紐解く。

—

1. なぜJSONPはXSSの特等席なのか

JSONPの仕組みは極めてシンプルだ。クライアントがURLパラメータに callback=handleResponse と指定すれば、サーバーはレスポンスを handleResponse({...data...}) というJavaScriptの関数呼び出しとしてラップして返す。

ここでの致命的な脆弱性は、「コールバック関数名のバリデーション不備」にある。攻撃者はここを突き、悪意のあるスクリプトを注入する。

攻撃シナリオ：コールバック注入

例えば、以下のようなURLを想像してほしい。
https://api.victim.com/data?callback=

サーバー側がこの callback パラメータを正規表現等で厳格にチェックせず、そのままレスポンスに埋め込んだ場合、ブラウザはそれを「信頼されたサーバーからの動的スクリプト」と誤認し、即座に実行する。これは反射型XSSの亜種だが、SOPをすり抜けるという点で非常にタチが悪い。

// サーバーサイドの脆弱な実装例 (Node.js/Express)
app.get(‘/api/data’, (req, res) => {
const cb = req.query.callback; // ここが地獄の入り口
const data = { user: ‘admin’, secret: ‘… ‘ };

// 攻撃者が callback にを仕込むと…
// Content-Type: application/javascript として実行されてしまう
res.send(${cb}(${JSON.stringify(data)}));
});

—

2. 根本原因：コンテキストの混同とMIMEタイプの脆弱性

ブラウザがなぜこの攻撃を許すのか。それは、