クリックジャッキングの仕組みとフレーム制御による対策

クリックジャッキングは、利用者が画面で見ているボタンやリンクと、実際にクリックされる要素とがすり替えられている攻撃です。攻撃者は自分が用意したページの前面に、標的となる正規サイトを透明なiframeで重ね、その奥に無害そうなボタンを見せます。利用者は見えているボタンを押したつもりでも、実際にはその手前にある透明なiframe内の正規サイトの操作要素をクリックしており、送金や設定変更、権限付与といった意図しない操作が実行されます。UIリドレッシング（UI Redressing）とも呼ばれます。

この記事では、クリックジャッキングがどのような重ね合わせで成立するのか、何が実行され得るのか、そしてサーバー側のフレーム制御を中心にどう防ぐのかを、開発者向けに整理します。攻撃を再現する手順や実際に動くコードは示しません。動作確認を行う場合は、自組織が管理する検証環境に限って実施してください。

クリックジャッキングが成立する仕組み#

攻撃者のページは、標的サイトのページを<iframe>で読み込み、CSSで不透明度をゼロ近くまで下げて透明化します。そのうえで、利用者に見せたいボタンやコンテンツを、透明なiframeの操作要素とちょうど重なる位置に配置します。透明化された標的サイトのiframeが最前面にあり、利用者の目にはその奥に置かれた見せかけのボタンだけが映る状態になります。

利用者が見えているボタンをクリックすると、透明なiframeが最前面にあるため、実際にクリックされるのは奥の見せかけの要素ではなく、前面の透明なiframe内にある標的サイトの本物の操作要素です。標的サイトは利用者が既にログイン済みであれば、そのセッションのまま操作を受け付けます。マウス位置に合わせて標的サイトを動かし、複数回のクリックを誘導する手法もあります。

この弱点はCWE-1021（Improper Restriction of Rendered UI Layers or Frames）として整理されています。派生には、SNSのいいねボタンを押させるLikejacking、カーソルの表示位置を実際の位置とずらして誤操作させるCursorjackingなどがあります。

CWE-1021は、Webアプリが他のアプリケーションやドメインに属するフレームやUIレイヤーを適切に制限しない弱点で、クリックジャッキングやUIリドレス攻撃とも呼ばれると定義しています。

何が実行され得るか#

クリックジャッキングで盗まれるのは、多くの場合データそのものではなく操作です。ページ内のテキストを読み取るのではなく、利用者のセッションを使って利用者本人に代わって操作を実行させる点が特徴です。標的が扱う機能に応じて、次のような操作が悪用の対象になります。

いずれも利用者本人が正規サイト上で実行できる操作であり、クリックジャッキングはその実行タイミングと対象を攻撃者が誘導している状態です。したがって、標的サイト側が枠内表示そのものを制御できれば、この誘導は成立しなくなります。

OWASPはクリックジャッキングを、透明または不透明なレイヤーを使って利用者を騙し、別ページのボタンやリンクをクリックさせる攻撃と説明しています。利用者は最上位のページをクリックしているつもりでも、実際は隠されたページの要素を操作しています。

主対策はCSPのframe-ancestors#

現行の推奨対策は、Content-Security-Policyヘッダのframe-ancestorsディレクティブで、自サイトを枠内に表示できるオリジンを宣言的に制限することです。frame-ancestorsは<frame>、<iframe>、<object>、<embed>による埋め込みについて、直接の親だけでなく全ての祖先フレームのオリジンを検査し、一つでも許可リストに無ければ読み込みを拒否します。ネストしたフレーム構成では、全ての祖先オリジンを許可リストに含める必要があります。枠内表示を一切許可しない場合は次のように設定します。

Content-Security-Policy: frame-ancestors 'none';

自サイト自身からの埋め込みだけを許可する場合は'self'を、特定の信頼オリジンからの埋め込みを許可する場合はホストを列挙します。

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

OWASPは、埋め込みの必要が特定できない限り枠内表示を許可しない設定を推奨しています。frame-ancestorsはdefault-srcにフォールバックしないため、default-src 'none'を設定していても埋め込み制御には別途frame-ancestorsの記述が必要です。なお、frame-ancestorsは<meta>要素では指定できず、HTTPレスポンスヘッダとして返す必要があります。

MDNはframe-ancestorsを、ページをフレームや埋め込み要素で読み込める親を指定するディレクティブと説明しています。値には'none'、'self'、ホスト、スキームを指定でき、default-srcへのフォールバックはなく、metaタグでは指定できません。

X-Frame-Optionsとの使い分け#

X-Frame-Optionsは、frame-ancestorsが標準化される前から使われてきたヘッダで、DENYとSAMEORIGINの2つの値を実務では使います。DENYはあらゆるオリジンからの枠内表示を禁止し、SAMEORIGINは同一オリジンからの埋め込みのみを許可します。かつて存在したALLOW-FROMは非推奨で、モダンブラウザではサポートされていません。特定オリジンへの許可が必要な場合はframe-ancestorsで表現します。

X-Frame-Options: DENY

frame-ancestorsとX-Frame-Optionsを両方返した場合、frame-ancestorsに対応するブラウザはCSPのframe-ancestorsを優先し、X-Frame-Optionsを無視します。frame-ancestorsを主対策としつつ、それに未対応な古いブラウザ向けの後方互換としてX-Frame-Optionsを併記する、という重ね方が現実的です。ただしX-Frame-Optionsが実質的に表現できるのはDENYとSAMEORIGINだけで、ALLOW-FROMは廃止済みのため、第三者オリジンの許可をX-Frame-Optionsで同じ範囲に表現することはできません。両者を完全に整合させられるのは概ねframe-ancestors 'none'とDENY、'self'とSAMEORIGINの場合に限られ、第三者オリジンを許可する構成では、frame-ancestorsに未対応な古いブラウザで埋め込みが拒否されるなど後方互換の差が出ます。

OWASP Clickjacking Defense Cheat Sheetは、CSPのframe-ancestorsを主たる制御として推奨し、X-Frame-Optionsは後方互換のための緩やかな縮退として位置づけています。両方が設定された場合、frame-ancestors対応ブラウザはX-Frame-Optionsを無視します。

ヘッダだけに頼らない多層防御#

フレーム制御ヘッダは主対策ですが、それだけに頼らず操作側の保護を重ねます。送金や権限変更のような不可逆または影響の大きい操作には、実行直前の再認証や確認ステップを設けると、1回のクリックでは完了しなくなり、誘導の成立を妨げられます。なお、anti-CSRFトークンの検証はクリックジャッキングそのものを防ぐ緩和策にはなりません。枠内に読み込まれた正規ページ自身が有効なトークンを保持しており、そこから正規のリクエストが送られてしまうためです。CSRF対策はクロスサイトリクエストフォージェリという別の脅威に対する必須の対策として、クリックジャッキング対策とは切り分けて実装します。

CookieのSameSite属性をLaxまたはStrictにすると、クロスサイトのiframeからのリクエストにセッションCookieが付与されにくくなり、影響を緩和できます。一方、JavaScriptでフレーム内表示を検出して抜け出すフレームバスティングは、サンドボックス属性などで無効化され回避されやすく、単独の対策としては不十分です。フレームバスティングを使う場合でも、ヘッダによる制御を主とし、あくまで補助に留めます。

OWASP Clickjacking Defense Cheat Sheetは、JavaScriptによるフレームバスティング（frame breaking）は無効化や回避が可能で信頼性が低いため、CSPのframe-ancestorsとX-Frame-Optionsによるサーバー側のフレーム制御を主たる防御とすべきと述べています。

導入と検証の手順#

関連する対策との位置づけ#

クリックジャッキング対策はフレーム制御が中心です。状態変更リクエストを扱うという点では、クロスサイトからの偽装リクエストを防ぐCSRF対策も欠かせませんが、これは枠内の正規ページ自身が有効なトークンを持つクリックジャッキングとは別の脅威への対策です。両者はそれぞれ異なる経路の意図しないリクエストを塞ぐ、独立した防御層として理解します。

あわせて読みたい

CSRFとは何か。仕組みからトークン・SameSite Cookieによる対策まで実務目線で解説

また、frame-ancestorsはContent-Security-Policyの一部であり、他のセキュリティHTTPレスポンスヘッダと合わせて設定することで運用が一貫します。ヘッダ全体の整理は次の記事にまとめています。

あわせて読みたい

セキュリティHTTPレスポンスヘッダで多層防御を固める方法

まとめ#

クリックジャッキングは、標的サイトを透明なiframeで前面に重ね、見えている偽のUIをクリックしたつもりの操作を透明なiframe内の正規要素に実行させる攻撃で、CWE-1021に分類されます。被害はデータの読み取りよりも、利用者のセッションを使った意図しない操作の実行にあります。防御の中心は、CSPのframe-ancestorsディレクティブで枠内表示を許可するオリジンを宣言的に制限することです。frame-ancestorsを主対策とし、未対応ブラウザ向けにX-Frame-OptionsのDENYまたはSAMEORIGINを併記します。さらに重要操作には確認ステップや再認証を課し、SameSite Cookieを重ねることで、フレーム制御だけに依存しない多層の構えを取ります。なお、anti-CSRFトークンはクリックジャッキング自体を防ぐものではなく、別の脅威への必須対策として切り分けて実装します。