>
>
公開日
最終更新日
IPAはHTTPレスポンスヘッダによる枠組み制御などを、Webサイト構築・運用時のクリックジャッキング対策として示しています。
クリックジャッキングは、利用者が正規サイトにログインしている状態で、退会、権限変更、購入確定、外部サービス連携の許可といった操作を意図せず実行させる攻撃です。攻撃ページ側で透明なフレームを重ねるため、サーバーログ上は正規ユーザーによる通常操作に見えやすい特徴があります。
情シス担当者が優先すべきなのは、WAFルールの追加ではなく、ブラウザが自社ページを外部サイトのframeに表示できないようにするレスポンスヘッダーの設計です。本記事では、CSPのframe-ancestorsを主軸に、互換性のためのX-Frame-Options併記、AWS CloudFrontでの設定、業務連携を止めないための事前検証まで解説します。
クリックジャッキングとは
クリックジャッキングとは、攻撃者が画面上の見た目と実際にクリックされる要素をずらし、利用者に意図しない操作を実行させるUI偽装攻撃です。
本記事のポイント
クリックジャッキングの主対策は、HTTPレスポンスヘッダーでframe埋め込みを制限することです。
CSPのframe-ancestorsを主軸にし、X-Frame-Optionsを互換性対策として併記します。
WAF単体はブラウザ上のフレーム重ね合わせを直接防止できません。
CloudFrontで設定する場合も、iframe利用箇所と外部連携を検証してから段階適用します。
攻撃の仕組み
典型例では、攻撃者が用意したページに正規サイトをiframeで読み込み、CSSで透明化したり座標をずらしたりします。利用者には「抽選に参加する」「資料を表示する」といった無害なボタンが見えていても、実際には背後に置かれた正規サイトの「購入を確定する」「連携を許可する」などのボタンを押す構造です。
クリックジャッキングは、クリック自体が利用者のブラウザで行われます。そのため、認証済みCookie、ログインセッション、画面上で発行済みのCSRFトークンが正規の状態で利用される場合があります。重要操作を1クリックで完了させる設計ほど、被害が大きくなります。
情シスが管理対象に含める画面
対象は公開Webサイトだけではありません。顧客向け会員サイト、管理者ポータル、社内申請システム、SaaS連携画面、ECサイトの購入確定画面など、ログイン状態で状態変更ができる画面を対象にします。特に、権限付与、メールアドレス変更、退会、送金先変更、OAuth認可、APIキー発行などは優先度を上げます。
国内における位置付け
IPAは「安全なウェブサイトの作り方」で、SQLインジェクション、クロスサイト・スクリプティング、クリックジャッキングを含む11種類の脆弱性を扱っています。ヘッダー設定の不備は外部から比較的容易に観測できるため、資産管理と継続診断の対象に含めます。
ヘッダー設定のような基本対策は、個別案件での対応にとどめず、開発・運用標準に組み込む形で継続的に管理します。
▲ 透明なiframeと重ね合わせ罠による攻撃の構造
クリックジャッキングと類似攻撃の違い
クリックジャッキングは利用者の視覚的な誤認を利用する攻撃であり、CSRFやフォームジャッキングとは防御する場所が異なります。
比較項目 | クリックジャッキング | CSRF | フォームジャッキング |
|---|---|---|---|
主な攻撃対象 | 利用者のクリック操作と画面表示 | 認証済みセッションによるリクエスト | 入力フォーム内のデータ |
代表的な手口 | 透明iframeや重ね合わせ | 罠サイトからの不正リクエスト送信 | 悪性JavaScriptによる入力値の窃取 |
主対策 | CSP frame-ancestors、X-Frame-Options | CSRFトークン、Origin検証、SameSite Cookie | スクリプト管理、CSP、改ざん監視 |
WAFの役割 | 直接の防止策ではない | 補助的な検知・遮断に利用可能 | 既知パターンの検知を補助 |
CSRFとの相違
CSRFは、利用者が攻撃サイトを訪れることをきっかけに、対象サービスへ不正なリクエストを送る手口であり、利用者が意図したリンク先への遷移や画像の読み込みなど通常のブラウザ動作を悪用します。一方、クリックジャッキングは利用者が画面をクリックするため、リクエストの送信元やトークンが正規の条件を満たしてしまうことがあります。したがって、CSRFトークンだけではクリックジャッキングの代替対策になりません。
状態変更を伴う画面では、CSRF対策とframe埋め込み制限を併用します。さらに送金、退会、権限昇格などの高リスク操作は、パスワード再入力、多要素認証、確認画面などを挟み、1回のクリックだけで完了しない画面設計にします。
ダブルクリックジャッキング
ダブルクリックジャッキングは、利用者に短時間で2回クリックさせる誘導を利用します。1回目でポップアップを閉じたように見せ、直後にウィンドウや要素の位置を入れ替え、2回目で認可や購入確定のボタンを押させます。iframeを禁止していても、別ウィンドウの切替や画面遷移を利用した類似のUI欺瞞が成立する可能性があるため、重要操作の再認証と確認画面が保険になります。
WAFとCDNの役割
WAFは、HTTPリクエストの内容、既知の攻撃パターン、異常なアクセス頻度などを評価して遮断する仕組みです。しかし、クリックジャッキングの本質は、攻撃サイトが利用者のブラウザ内で正規ページをframe表示することにあります。一般的なWAFは、他ドメインのページが自社ページをframeに読み込むブラウザ表示を単体では制御できません。
CDNやWebサーバーは、レスポンスにCSPやX-Frame-Optionsを付与できるため、クリックジャッキング対策の実施場所になります。WAFを導入済みでも、レスポンスヘッダーを送出していなければframe埋め込みは防げません。WAFはSQLインジェクションや既知の悪性リクエスト対策、CDN・Webサーバーはフレーム制御というように責任範囲を分けます。
被害事例とスマホ環境の手口
クリックジャッキングによる被害は、SNS投稿からECサイトの購入確定、業務システムの権限変更まで、ログイン済み画面の機能に応じて広がります。
ECサイトと会員サイトの被害
ECサイトのクリックジャッキング対策では、購入確定、配送先変更、定期購入の変更、ポイント利用、退会といった画面を優先して確認します。攻撃者はゲーム、アンケート、キャンペーン応募のような画面を作り、その上に購入確定画面を重ねることがあります。決済情報を直接盗むフォームジャッキングとは異なりますが、ログイン済みの利用者に注文を確定させれば、返金対応、調査、問い合わせ増加、信用低下につながります。
会員サイトでも同様です。メールアドレスや連絡先の変更、外部アプリ連携の許可、通知設定の変更は、攻撃者がアカウント回復や情報取得につなげる足掛かりになります。画面単位でframe埋め込み可否を決めず、サービス全体の認証・状態変更画面を棚卸ししてポリシーを定義します。
スマホにおける画面欺瞞
スマホではマウスカーソルがなく、利用者は指で直接タップします。画面が小さく、ブラウザのアドレスバーや遷移先を十分に確認しにくいため、視覚的な誘導が成立しやすい環境です。Webサイト運営者側の基本対策はPCと同じで、外部サイトからのframe埋め込みをCSPで制限します。
近年は、Androidの画面遷移アニメーションを悪用するTapTrapと呼ばれる攻撃手法が、学術・セキュリティ研究者によって公表されています（公表元および論文情報については、利用可能な出典一覧に含まれる資料では確認できていないため、詳細は各自でACMやUsenixなどの学術論文データベースを参照してください）。この手口は通常のWebページだけで一律に成立するものではなく、悪意あるAndroidアプリが端末上の画面遷移や重ね合わせに介在することが前提であり、影響範囲はそのアプリをインストールした端末に限られます。情シスでは、WebのCSP対策とは別に、業務端末で利用を許可するアプリ配布経路、端末管理、OS更新方針を管理対象として切り分けます。
DOMベース拡張機能型の手口
DOMベースの拡張機能クリックジャッキングは、パスワードマネージャーや暗号資産ウォレットなどのブラウザ拡張機能がページ上に追加するUIを狙う手口です。従来型のように正規サイト全体をiframeに収めるのではなく、攻撃サイト内の不可視要素や位置関係を悪用し、拡張機能の自動入力や承認操作を誘導します。
この類型は、自社WebサイトのX-Frame-Optionsだけで完結して防げる問題ではありません。情シスが管理するブラウザでは、拡張機能の許可リスト、更新状況、パスワード自動入力の設定を別の統制項目として扱います。一方で、会員サイト側ではOAuth認可、APIキー表示、支払設定変更などに再認証を設け、誤操作されても被害が確定しにくい設計にします。
過去の対策状況
ヘッダー設定の漏れは長期運用されたサイトや外部委託の旧画面で残りやすいため、現行資産の実測確認が有効です。
レスポンスヘッダーによる防御設計
クリックジャッキング対策は、CSPのframe-ancestorsを主軸にし、必要な互換性を考慮してX-Frame-Optionsを併記する設計が実務的です。
CSPのframe-ancestors
frame-ancestorsは、自社ページをどのサイトがframe、iframe、objectなどで埋め込めるかを指定するCSPディレクティブです。埋め込みが不要な画面では、Content-Security-Policy: frame-ancestors 'none'; を設定します。同一オリジン内の埋め込みだけを許可する場合は、Content-Security-Policy: frame-ancestors 'self'; を使用します。
外部の正規パートナーに埋め込みを許可する業務要件がある場合は、Content-Security-Policy: frame-ancestors 'self' のように許可元を明示します。ワイルドカードで広く許可すると、ポリシーの意味が薄れます。許可先が確定している場合だけ個別のオリジンを列挙し、許可先が確定できない画面は埋め込み禁止にします。
X-Frame-Optionsの併記
X-Frame-Optionsは古いブラウザを含む互換性対策として現在も有効です。外部からの埋め込みをすべて禁止するなら、X-Frame-Options: DENY を併記します。同一オリジンでの埋め込みを許可する場合は、X-Frame-Options: SAMEORIGIN を併記します。
ただし、X-Frame-Optionsは複数の外部ドメインを柔軟に指定する用途には向きません。過去に使われたALLOW-FROMはブラウザ間の相互運用性が乏しいため、外部パートナーを許可する要件ではCSPのframe-ancestorsを正とします。外部パートナーをCSPで許可しながらX-Frame-Options: SAMEORIGINを同時に送る場合、現代のブラウザはframe-ancestorsを優先するためパートナーの埋め込みは機能しますが、frame-ancestorsを解釈できない旧ブラウザはSAMEORIGINだけを見てパートナー埋め込みを拒否します。旧ブラウザ向け互換性が前提なら、X-Frame-Optionsの値を外部パートナー許可画面にそのまま流用しないことを確認したうえで、対象ブラウザ範囲と許可要件を照合して設定を決めます。IPAは「安全なウェブサイトの作り方」補足資料（クリックジャッキングページ）でInternet Explorer 7がX-Frame-Optionsに対応していないことを明記しています。サポート対象ブラウザにIE7以前が含まれる場合は、X-Frame-Optionsだけでは制御が完結しないため、JavaScriptによるFrame-Bustingなど別の軽減策を併用するかどうかを対象ブラウザ範囲に基づいて判断します。
ヘッダー設定の確認方法
設定後は、ブラウザ開発者ツールのNetworkタブで対象ページのレスポンスヘッダーを確認します。コマンドラインを使える運用では、curl -I https://対象ドメイン の結果にCSPとX-Frame-Optionsが含まれるかを確認します。ログイン後にしか表示されない画面は、認証済みブラウザの開発者ツールで確認します。
複数のCSPヘッダーがオリジン、CDN、アプリケーションから重複送信されると、ブラウザは各ポリシーを個別に適用します。結果として意図より厳しい制限になり、正規の埋め込みが止まることがあります。オリジン側で既にCSPを返している場合は、CloudFront側で上書きするのか、CSPを一元化するのかを決めてから設定します。
Frame-Bustingの限界
JavaScriptでtop.locationを書き換え、iframeから親ページへ脱出しようとするFrame-Bustingは補助的な表示制御にすぎません。攻撃者はiframeのsandbox属性を利用し、トップレベルへの遷移を制限することで、この処理を妨げられます。また、JavaScriptが無効な環境や実行前の描画に依存するため、セキュリティ制御として採用しません。
やってはいけないのは、HTMLのmeta要素だけでframe-ancestorsを設定して完了と判断することです。frame-ancestorsはHTTPレスポンスヘッダーとして送信する必要があります。HTMLテンプレートを修正しても、Networkタブでレスポンスヘッダーに存在しなければ、クリックジャッキング対策としては未実装です。
▲ 画面の要件に応じたCSP frame-ancestorsの設定判断フロー
AWS CloudFrontでの適用フロー
AWSでクリックジャッキング対策を一元適用する場合は、CloudFrontのレスポンスヘッダーポリシーを使い、オリジン設定との責任分担を明確にします。
CloudFrontの設定手順
CloudFrontを経由して配信している画面では、Response Headers Policyでセキュリティヘッダーを付与できます。オリジンのソースコードをすぐに修正できない場合でも、CDN側で段階的に設定を展開できます。ただし、CloudFrontによるヘッダー付与はWAF機能ではなく、CDNのレスポンス制御です。
CloudFrontコンソールでレスポンスヘッダーポリシーを新規作成します。
対象画面の埋め込み要件に合わせて、CSPの値を定義します。原則は
frame-ancestors 'self'または'none'です。互換性が必要な場合は、X-Frame-OptionsにDENYまたはSAMEORIGINを設定します。
ポリシーを対象ディストリビューションのBehaviorへ関連付けます。
キャッシュ反映後、通常画面とログイン後画面の両方でレスポンスヘッダーを確認します。
CloudFrontの管理ポリシーを利用する場合でも、CSPにframe-ancestorsが含まれているかは個別に判断します。クリックジャッキング対策の要件を満たすかは、ポリシー名ではなく、実際にブラウザへ返るヘッダー値で決まります。
導入前の検証フロー
一律にframe-ancestors 'none'を適用すると、正規の埋め込みまで停止します。設定前に以下の順で洗い出すと、画面崩れや業務停止を減らせます。
検証段階 | 確認内容 | 判断 |
|---|---|---|
資産棚卸し | ログイン画面、管理画面、会員画面、決済画面のURLと所有部署 | 所有者が不明な画面は全体適用前に保留します。 |
iframe調査 | 自社が親ページとして埋め込む機能と、自社ページが埋め込まれる機能 | 外部埋め込みが不要ならnone、自社内だけならselfにします。 |
連携確認 | 決済代行、SSO、帳票表示、サポートチャット、BIダッシュボード | 正規の外部埋め込みが必要なら、CSPに許可元を個別追加します。 |
限定展開 | 検証用Behaviorまたは限定パスでのヘッダー適用 | 障害がなければ本番範囲を広げ、問題が出れば許可元または構成を見直します。 |
継続監視 | リリース後のヘッダー、ブラウザエラー、連携障害 | 新規画面が増える場合は診断ルールと設計標準に追加します。 |
オリジンとCDNの責任分担
アプリケーションチームが画面単位の例外を把握しているなら、オリジンでCSPを設定する方法が適します。多数の静的サイトや改修困難なレガシー画面を同じCloudFront配下で運用しているなら、CDNで共通ヘッダーを適用し、例外画面だけ別Behaviorに分離します。
いずれの場合も、オリジンとCloudFrontの両方で異なるCSPを設定して偶然動作させる構成は避けます。どちらが最終値を管理するかを決め、変更手順、ロールバック方法、確認担当を運用台帳に残します。
▲ CloudFrontによるヘッダー適用手順（4ステップ）
診断と運用手段の選び方
クリックジャッキング対策は、ヘッダー設定、継続診断、重要画面の手動検証を組み合わせると、設定漏れと変更後の劣化を管理できます。
手段 | 主な目的 | クリックジャッキングへの有効性 | 注意点 |
|---|---|---|---|
Webサーバー・アプリ改修 | 画面単位の厳密なポリシー設定 | 根本対策 | 改修対象の漏れと既存連携への影響を管理します。 |
CDNのヘッダー制御 | 複数サイトへの共通設定 | 根本対策を補助 | オリジン側CSPとの重複を防ぎます。 |
WAF | 悪性リクエストや既知攻撃の防御 | 直接対策ではない | frame制御の代替として扱いません。 |
自動脆弱性診断 | ヘッダー不備や公開資産の継続検知 | 設定漏れの発見に有効 | 検知後の修正担当と期限を決めます。 |
手動脆弱性診断 | 重要業務フローの個別検証 | 複合的なUI欺瞞の確認に有効 | リリースごとの即時検証には向きません。 |
自動診断の位置付け
自動診断は、X-Frame-OptionsやCSPの未設定を横断的に見つける用途に向きます。AeyeScanは2024年にX-Frame-Optionsレスポンスヘッダーの不備を確認するスキャンルールを追加し、その評価をCVSS 0.0、深刻度Infoとして公式リリースノートで案内しています（評価値はCVSS v3.1に基づき、ヘッダー不備単体では悪用に追加条件が必要なことを反映したものです）。これはヘッダー不備だけで直ちに重大被害が確定するわけではないことを示しますが、ログイン画面や状態変更画面で見つかった場合は、業務上の影響を踏まえて優先度を上げます。
自動診断で未設定を検知したら、画面の用途、iframe利用の有無、重要操作の有無を確認します。外部埋め込みが不要で重要操作を含む画面なら、CSPとX-Frame-Optionsの設定変更へ進みます。正規の埋め込みが存在するなら、許可元を確定させて限定ポリシーを作成します。
手動診断の位置付け
手動診断は、画面遷移、SSO、決済、権限変更など、実際の業務フローをまたぐ確認に向きます。診断会社の報告書だけを受領して終わらせず、指摘されたURL、設定値、修正責任者、再診断日を脆弱性管理台帳に記録します。
IPAは2025年5月16日にサイバー対処能力強化法が成立したことを受け、制度施行後は脆弱性対応の強化が図られると案内しています。法令対応の有無だけで優先順位を決めるのではなく、外部公開され、認証済み操作を提供し、埋め込み制御がない画面から対応します。
運用基準への組み込み
新規開発の非機能要件には、frame-ancestorsの方針、X-Frame-Optionsの値、外部埋め込みの許可元、検証方法を記載します。リリース時には、レスポンスヘッダーの確認を完了条件に入れます。これにより、クラウド移行やCDN切替でヘッダーが欠落する問題を早期に検知できます。
導入時の失敗パターン
クリックジャッキング対策は、ヘッダーを追加するだけで完了させると、正規連携の停止や設定漏れを引き起こします。
一律禁止による業務停止
frame-ancestors 'none'は最も明快な設定ですが、外部ポータルへの埋め込み、SSO画面、決済補助画面、BIレポート、サポートツールなどがiframeを使っている場合、表示不能になる可能性があります。埋め込み利用が確認できれば、親となる正規オリジンだけをCSPに追加します。利用の根拠が確認できなければ、例外を広げずに埋め込み禁止を維持します。
WAF導入による誤解
WAFを導入していることを理由に、CSPやX-Frame-Optionsを省略するのは失敗です。WAFは攻撃リクエストの検査を担いますが、外部サイトが自社画面をiframeで表示するかどうかは、ブラウザに返すレスポンスヘッダーで決まります。WAF運用とヘッダー管理を別の統制項目にし、責任者も明確にします。
古い設定だけへの依存
X-Frame-OptionsのSAMEORIGINやDENYは現在も有効な軽減策です。しかし、複数の外部パートナーを許可する細かな制御には対応しにくいため、CSPを使わずにX-Frame-Optionsだけで例外管理を続けると、要件変更時に破綻しやすくなります。外部埋め込みが必要な画面はCSPを正とし、X-Frame-Optionsは互換性目的で併記します。
確認不足による設定漏れ
トップページだけでヘッダーを確認し、会員画面や管理画面を確認しないケースもあります。CDNのBehavior、別サブドメイン、旧システム、リダイレクト後の画面では、異なる設定が返ることがあります。資産台帳で対象URLを管理できるなら、定期診断の対象リストと連動させます。台帳がない場合は、まず認証を必要とする外部公開画面から一覧を作り、確認範囲を段階的に広げます。
よくある質問
クリックジャッキング対策の導入・運用時に実際に直面しやすい疑問を、Webシステム運用の判断に必要な範囲で整理します。
バナー上の透明な要素による誘導
Q：一見問題のなさそうなバナー上に、透明なバナーを重ねておき、クリックした閲覧者を攻撃用のサイトに誘導する手口は何ですか。
A：クリックジャッキングです。利用者が見ているバナーと実際にクリックする要素をずらし、意図しない画面遷移や操作を実行させます。
ダブルクリックジャッキングの意味
Q：ダブルクリックジャッキングとは何ですか。
A：利用者に2回のクリックをさせ、1回目の直後に画面やウィンドウの状態を切り替えて、2回目を重要操作に当てる手口です。frame埋め込み制限に加え、権限付与や購入確定に再認証・確認画面を設けることで被害を抑えます。
AWSでのクリックジャッキング対策
Q：AWSでCloudFrontを使う場合、ヘッダーはコンソールのどこで設定しますか。
A：CloudFrontコンソールで「ポリシー」→「レスポンスヘッダー」から新規ポリシーを作成し、CSPのframe-ancestorsとX-Frame-Optionsを追加します。作成したポリシーをディストリビューションの対象Behaviorに関連付けると、そのパス配下のレスポンスにヘッダーが付与されます。設定後はブラウザ開発者ツールのNetworkタブで実際に返るヘッダー値を確認し、連携機能（SSO、決済など）が正常に動くことを同時に検証します。
X-Frame-OptionsだけとCSP併用の違い
Q：X-Frame-OptionsのSAMEORIGINだけでなく、CSPのframe-ancestorsも設定する理由は何ですか。
A：X-Frame-Optionsでは複数の外部オリジンを列挙する細かな制御ができません。外部パートナーへの埋め込み許可が生じた場合、CSPのframe-ancestorsなら許可元を個別に明示できます。現代のブラウザはCSP frame-ancestorsを優先して解釈するため、両方を設定するとCSPが実質的なポリシーとなり、X-Frame-Optionsは古いブラウザ向けの互換性補完として機能します。
まとめ
クリックジャッキング対策の出発点は、WAF導入の有無ではなく、自社の認証済み画面が外部サイトのframeに読み込まれない設定になっているかを把握することです。CSPのframe-ancestorsを主軸に、X-Frame-Optionsを併記し、CloudFrontまたはWebサーバーでHTTPレスポンスヘッダーとして配信します。
明日から着手するなら、ログイン、権限変更、購入確定、退会、外部連携の画面を一覧にし、ブラウザ開発者ツールでCSPとX-Frame-Optionsを確認します。外部iframe利用が確認できれば許可元を限定したCSPを設計し、確認できなければ埋め込み禁止のポリシーを限定環境から適用します。設定値だけでなく、正規の決済・SSO連携が動くことまで検証して初めて対策が完了します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
