クリックジャッキングとフレーミング防御（frame-ancestors）

クリックジャッキング（clickjacking、UI redress attack）は「被害者が押したつもりのボタンと、実際に押させられたボタンが違う」攻撃です。攻撃者は自分のページに被害サイトを iframe で埋め込み、それを透明にして無関係なコンテンツの上に重ねます。被害者は表面のおとりを操作しているつもりで、裏に隠れた本物の「送金」「権限付与」ボタンをクリックさせられます。CSRF と違いリクエストを偽造するのではなく、被害者自身の本物のクリックを盗む点が本質です。

透明 iframe 重ね合わせの原理

攻撃の土台は「外部サイトを iframe で埋め込める」という Web 標準の機能と、CSS で要素を不可視化・重ね合わせできることの組み合わせです。攻撃者ページは被害サイトを iframe に読み込み、opacity: 0 で透明にしたうえで、position と z-index で前面に置きます。その真下に、被害者を誘導するおとり（「無料プレゼントを受け取る」等）を配置します。

<style>
  iframe {
    position: absolute; top: 0; left: 0;
    width: 500px; height: 500px;
    opacity: 0;            /* 透明にして見えなくする */
    z-index: 2;            /* おとりより前面に重ねる */
  }
  #decoy { position: absolute; top: 240px; left: 60px; z-index: 1; }
</style>
<div id="decoy">無料プレゼントはこちら</div>
<!-- 被害サイト。透明だが、クリックは iframe 側に届く -->
<iframe src="https://bank.example/transfer-confirm"></iframe>

ここで効いている仕組みは、ヒットテスト（hit testing）です。ブラウザはクリック座標に対し、最前面にある要素を当たり判定の対象に選びます。opacity: 0 は要素を不可視にするだけで、レイアウト上は存在し続けポインタイベントも受け取ります。つまり被害者の目には「無料プレゼント」ボタンが見えていても、実際のクリックは最前面の透明 iframe 内の本物のボタンへ届きます。攻撃者は iframe の表示位置を CSS で微調整し、おとりの真上に本物のボタンが来るよう座標を合わせ込みます。

クリック以外に、ドラッグ＆ドロップでフォームに値を流し込ませる、キー入力を奪う（keyjacking）、pointer-events を切り替えてクリックの一部だけを透過させる、といった派生があります。いずれも「被害者の正規な操作を、別の標的へ向け直す」点で共通します。

防御の主軸 — 埋め込みをブラウザに拒否させる

クリックジャッキングは攻撃者ページが被害サイトを iframe に入れられることが前提です。したがって本質的な防御は、被害サイト側が「自分のページを iframe に埋め込んでよい相手」をブラウザへ宣言し、許可外の埋め込みをブラウザにレンダリング段階で拒否させることです。これを担うのが、古い X-Frame-Options ヘッダと、現行標準である CSP の frame-ancestors ディレクティブです。

Content-Security-Policy: frame-ancestors 'self' https://partner.example

このヘッダ付きのレスポンスは、自分自身（'self'）と partner.example 以外のページから iframe 埋め込みされた場合、ブラウザがフレームの描画自体を拒否します。攻撃者の evil.example からの埋め込みは許可リストに無いので空フレームになり、透明にしようがクリックは届きません。

X-Frame-Options と frame-ancestors の違い

両者は目的が同じですが、表現力と仕様上の位置づけが異なります。X-Frame-Options は事実上 3 系統の値しか持たず、複数の許可オリジンを表現できません。frame-ancestors はソースリストで任意個のオリジンを並べられ、CSP の一部として正式に標準化されています。

値の対応関係は、X-Frame-Options: DENY が frame-ancestors 'none'、SAMEORIGIN が frame-ancestors 'self' に相当します。問題は ALLOW-FROM です。これは「この 1 オリジンだけ許可」を意図した値ですが、多くのブラウザが実装せず無視するか、指定すると逆に全拒否になる挙動差がありました。複数オリジンも書けません。つまり「特定パートナーだけ埋め込み許可」という現実的な要件は X-Frame-Options では満たせず、frame-ancestors でなければ正しく表現できません。

frame-ancestors は CSP の他のディレクティブと違い、default-src にフォールバックしません。default-src 'none' を書いても埋め込み制御はかからないので、フレーミング防御を意図するなら frame-ancestors を明示する必要があります。また CSP ヘッダが複数ある場合は全ポリシーの積（AND）で評価されるため、どれか 1 つでも厳しい frame-ancestors があればそれが効きます。

許可リストの設計と落とし穴

frame-ancestors のソースは「祖先（埋め込み元）ドキュメントのオリジン」と照合されます。多段にネストした iframe では、直接の親だけでなく全祖先が許可リストに合致する必要があります。途中に許可外オリジンが 1 つでも挟まれば拒否されます。これは「許可した相手の中にさらに攻撃者が iframe を仕込む」入れ子攻撃を塞ぐためです。

設計の原則は「埋め込みを許す積極的な理由が無ければ 'none'（または 'self'）にする」ことです。許可リストを広げるほど、許可先のいずれかが乗っ取られたりサブドメインを奪われたりした時の攻撃面が増えます。とりわけワイルドカードでサブドメイン全体を許す指定は、サブドメイン乗っ取り（dangling DNS など）と組み合わさると防御が骨抜きになります。許可は最小限のオリジンに絞り込みます。

ヘッダが効かない場面と多層防御

frame-ancestors はブラウザがヘッダを解釈して初めて効くため、ヘッダが攻撃者に制御される、あるいはレガシー環境でヘッダが届かない場合に備えた補強も要ります。古典的な保険が JavaScript のフレームバスター（frame busting）です。

// 自分がトップレベルでない（=フレームに入れられている）なら脱出
if (window.self !== window.top) {
  window.top.location = window.self.location;
}

ただしフレームバスターは万能ではありません。攻撃者が iframe に sandbox 属性を付けると、allow-top-navigation を与えない限り子フレームからの window.top.location 書き換えがブロックされ、脱出スクリプトが無力化されます。逆に言えば、JS 単体に頼ると sandbox で容易に回避されるため、あくまで frame-ancestors を主、JS を従とする位置づけにします。

クリックジャッキングが成立しても、副作用のあるリクエストにクロスサイトの Cookie が付かなければ被害は抑えられます。認証 Cookie に SameSite=Lax／Strict を付けておくと、別オリジンに埋め込まれたフレーム内からの操作で Cookie 送信が制限され、被害の前提を一段崩せます。SameSite の挙動は CSRFの成立条件と多層防御の原理 と Cookie とセッション を、なぜクロスオリジン iframe が隔離されるのかは 同一オリジンポリシーとサイト分離の信頼境界 を参照してください。

まとめると、クリックジャッキング対策の本筋は「全レスポンスに frame-ancestors を明示し、埋め込みをブラウザに拒否させる」こと。'none' か 'self' を既定にし、どうしても外部埋め込みが必要なページだけ最小のオリジンを許可します。その上で SameSite Cookie・JS フレームバスター・重要操作の再確認を重ね、ヘッダが届かない経路や入れ子攻撃でも崩れない多層構成にするのが、堅い設計です。