【テクニカル・上級編】CSPのobject-srcとbase-uriによるプラグイン・リダイレクト攻撃防御 – アプリケーションセキュリティ & 安全な開発防御ガイド

現代のフロントエンド防衛:CSPによる「プラグイン・ハイジャック」と「ベースタグ・インジェクション」の封殺

こんにちは。現場で泥をすすり、パケットの微かな揺らぎから侵入者の気配を察知する仕事をしている者です。

多くのエンジニアは、XSS(クロスサイトスクリプティング)と聞くと、alert(1)を出すスクリプトインジェクションを連想します。しかし、真の脅威はもっと狡猾です。モダンなWebアプリにおいて、JavaScriptの実行を止めるだけではもはや「防御」とは言えません。今回は、攻撃者が好む「足元の土台」を狙う攻撃と、それをCSP(Content Security Policy)で物理的に叩き潰すためのアーキテクチャ設計について深掘りします。

1. 忘れ去られた「プラグイン」という名のブラックボックス

かつてFlashやJavaアプレットが闊歩していた時代、ブラウザのプラグイン機能は攻撃者の格好の侵入経路でした。現在、ブラウザはそれらを排除しましたが、object-srcというCSPディレクティブが不要になったわけではありません。

攻撃者は依然として、やタグを利用し、攻撃者のサーバーから悪意のあるバイナリをロードさせようと試みます。もしCSPでobject-srcを制限していない場合、HTMLのレンダリングエンジンは、クロスドメインの制約を無視して外部リソースを「プラグイン」として解釈しようとします。これは単なるスクリプト実行を超え、ブラウザのレンダリングプロセスに直接介入する攻撃ベクトルになり得ます。

防御の鉄則:object-src 'none'

迷う必要はありません。現代のアーキテクチャにおいて、プラグインを許可すべき理由は皆無です。

CSPの基本防御設定
object-src を ‘none’ にすることで、プラグインの読み込みを根本から拒否する
Content-Security-Policy: default-src ‘self’; object-src ‘none’;

2. baseタグの悪用:URL解決をコントロールする「見えない支配」

XSS対策として多くの開発者がscript-srcに執着する一方で、base-uriを見落としています。これが致命的な盲点です。

HTMLのタグは、ページ内の相対パスの解決基準点を強制的に変更します。もし攻撃者が格納型XSSでを注入することに成功したらどうなるか? ページ内のすべての

securityintronationalをフォローする

コメント

タイトルとURLをコピーしました