「なぜCSPで object-src と base-uri を縛るのか？」――レガシーな脅威を現代のWebで封じ込める技術論
現場でインシデント対応をしていると、いまだに「CSP（Content Security Policy）はXSS対策でしょ？」と軽く捉えているエンジニアに出くわす。それは半分正解だが、残りの半分を見落としている。
今日のテーマは、多くの開発者が「古い技術だから関係ない」と油断している プラグイン・ハイジャック と、地味だが致命的な 相対パス・ハイジャック の防御だ。これらはCSPの特定のディレクティブを適切に設定するだけで、ほぼゼロコストで根絶できる。
1. なぜ今さら「プラグイン」を気にするのか？
「Flashは死んだし、Javaアプレットも過去のものだ」――確かにそうだ。しかし、攻撃者はアプリケーションの「不整合」を突く。
攻撃のシナリオ：プラグイン・ハイジャック
もし君たちが開発しているサイトで、HTMLインジェクションが可能だとしよう。攻撃者は や タグを注入し、悪意あるプラグイン（あるいは脆弱性のある古いブラウザ拡張機能）を読み込ませる。
PoC（概念実証）のイメージ:
ブラウザがこれを実行すれば、サンドボックスの外側でコードが走る可能性がある。現代のブラウザはプラグインを排除する方向に動いているが、レガシーな社内システムや、一部の特殊な環境では未だに「動いてしまう」ケースがある。これを物理的に防ぐのが object-src 'none'; だ。
2. 見過ごされがちな盲点：base-uri の恐怖
次に、もっと狡猾な攻撃手法である「Base URIハイジャック」について話そう。
攻撃の仕組み:
これだけで、君たちのアプリケーションは攻撃者の配布するスクリプトを「正当な自社コンテンツ」として実行する。パスワードを盗むのも、セッションを奪うのも一瞬だ。これを防ぐのが base-uri 'self'; である。
3. 実践：セキュアなCSP設定（コピペで使える）
机上の空論は終わりだ。実際にNginxやWebアプリケーションのレスポンスヘッダーに設定すべき構成を提示する。
Nginxでの設定例
Nginxのコンフィグ（nginx.conf）に以下を追記する。
強力なCSPヘッダーを付与
object-src ‘none’ でプラグイン実行を完全に禁止
base-uri ‘self’ でベースURLを自サイトのみに限定
add_header Content-Security-Policy “default-src ‘self’; object-src ‘none’; base-uri ‘self’; script-src ‘self’; style-src ‘self’ ‘unsafe-inline’;”;
PHPで動的に制御する場合
フレームワークを使わない古いシステムであれば、エントリーポイントで設定する。
4. セキュリティチーフからのアドバイス：実装時の注意点
この設定を本番環境にいきなり投入すると、思わぬところで「画面が真っ白」になることがある。以下の手順を徹底してほしい。
1. Report-Onlyモードで試す:
Content-Security-Policy-Report-Only ヘッダーを使い、まずはブロックせずにログだけを収集する。これで、現在のアプリケーションが意図せずプラグインや外部のベースタグに依存していないか確認できる。
2. サードパーティAPIとの兼ね合い:
もし自サイトで外部のプラグイン（例えば特定のレガシーなPDFビューア等）を意図的に使っている場合は、object-src を none ではなく、許可するドメインを指定する必要がある。だが、可能な限り none にすることを強く推奨する。
3. レガシーな相対パスへの依存を見直す:
base-uri 'self' を設定した際、もしサイトがルート相対パス（/js/...）ではなく、ディレクトリ相対パス（./js/...）でリソースを呼び出していると、リンクが切れる可能性がある。これを機に、全てのURLを絶対パスかルート相対パスに書き直すのが、プロのエンジニアの流儀だ。
まとめ
セキュリティは「魔法の杖」ではない。「必要のない機能は、物理的に動かないようにする」という引き算の哲学が、最も強固な防御になる。
object-src 'none' と base-uri 'self' 。この2行を追加するだけで、君たちのシステムは、何百もの脆弱性診断において「この部分は完璧だ」と胸を張れるようになる。泥臭い作業だが、今日すぐに手を動かしてくれ。君たちのコードを守れるのは、最後には君たちの判断だけだ。
コメント