「ボタンを1つクリックしただけなのに、勝手にSNSの設定が変わっていた」「Webカメラの許可を出した覚えがないのに、有効になっていた」――こうした被害の裏には、クリックジャッキングという攻撃手法が潜んでいる可能性があります。
クリックジャッキングは、ユーザーが見ている画面の上に透明なページを重ね、意図しない操作をクリックさせる攻撃です。見た目上は何の変哲もないボタンを押しているだけなのに、その裏では別のサイトの操作が実行されてしまいます。IPAの「安全なウェブサイトの作り方」でも対策が明記されており、Webサイトを運用するなら押さえておくべき脆弱性の一つです。
この記事では、クリックジャッキングの仕組み・被害パターン・具体的な防御策について、サーバー設定レベルの実践手順を含めて解説します。

クリックジャッキングとは?なぜ危険なのか
クリックジャッキング(Clickjacking)とは、攻撃者が用意したページの上に、標的となるWebサイトを透明なiframe(インラインフレーム)で重ね、ユーザーのクリック操作を「乗っ取る」攻撃手法です。「Click(クリック)」と「Hijacking(乗っ取り)」を組み合わせた造語で、「UI Redressing(UIの再配置)」とも呼ばれます。
クリックジャッキングが危険である理由は主に3つあります。
・ユーザーが自分の意志でクリックしている: フィッシングのように偽サイトにログインさせるのではなく、ユーザー自身が「クリックした」という事実が残るため、被害の立証が難しい
・既存の認証・セッションがそのまま使われる: 透明なiframe内で表示されているのは正規サイトそのものなので、ログイン済みの状態でそのまま操作が実行される
・攻撃の準備が容易: iframeとCSSだけで攻撃ページを構築できるため、高度なプログラミング知識がなくても攻撃が成立する
CSRFが「ユーザーの意図しないリクエストを送信させる攻撃」であるのに対し、クリックジャッキングは「ユーザー自身に意図しないクリック操作をさせる攻撃」です。どちらもユーザーの操作権限を悪用しますが、クリックジャッキングは「人間の操作そのもの」を騙す点でより巧妙です。
攻撃の仕組み ― クリックジャッキングはどのように成立するのか
クリックジャッキングの攻撃フローを順を追って見ていきましょう。
1. 攻撃者が罠ページを作成する
攻撃者は、標的サイトのページをiframeで読み込む罠ページを用意します。このiframeにはCSSで「opacity: 0」(完全に透明)を設定し、ユーザーの目には見えない状態にします。さらに、z-index(重なり順序)を高く設定して、罠ページの上に透明な標的サイトが浮いている構造を作ります。
2. ユーザーを罠ページに誘導する
攻撃者は、メールやSNSのリンク、広告バナーなどを使って罠ページにユーザーを誘導します。罠ページには「無料プレゼントはこちら」「動画を再生する」といった、思わずクリックしたくなるボタンが表示されています。
3. クリックが透明なiframeに吸い取られる
ユーザーが罠ページ上のボタンをクリックすると、実際にはその上に重なっている透明なiframe内の標的サイトのボタンがクリックされます。標的サイトにログイン済みであれば、「アカウント削除」「設定変更」「送金承認」といった操作がユーザーの意志に反して実行されてしまいます。
この攻撃の厄介な点は、ブラウザのセキュリティ機能では「ユーザーが自発的にクリックした」と判定されることです。JavaScriptの自動実行とは異なり、人間の物理的な操作が介在するため、クライアント側だけでは防御が困難です。

クリックジャッキングで発生する具体的な被害
クリックジャッキングによる被害は「1クリックで実行できる操作」すべてが対象になり得ます。代表的な被害パターンを見てみましょう。
| 被害パターン | 具体例 | 影響度 |
|---|---|---|
| SNSの「いいね」やフォロー | Facebookで特定ページを「いいね」させる(Likejacking)。2010年頃に大規模に悪用された | 中 |
| アカウント設定の変更 | メールアドレスやパスワードの変更確認ボタンをクリックさせ、アカウントを乗っ取る | 重大 |
| Webカメラ・マイクの許可 | ブラウザの権限許可ダイアログを透明に重ね、カメラ・マイクのアクセス許可をクリックさせる(過去に実証された攻撃) | 重大 |
| ワンクリック決済の実行 | ECサイトの「購入する」ボタンをクリックさせ、登録済みの決済手段で購入を完了させる | 重大 |
| 管理画面の操作 | CMSの管理画面で「ユーザー削除」「権限変更」「プラグイン有効化」などの操作を実行させる | 重大 |
特にWordPressなどのCMS管理画面はクリックジャッキングの標的になりやすいです。管理者がログインした状態で罠ページにアクセスすると、プラグインの有効化やユーザーの追加といった操作が1クリックで実行されかねません。
具体的な防御手順
クリックジャッキングの防御は「自サイトのページがiframeに埋め込まれることを阻止する」のが基本です。サーバー側のHTTPヘッダー設定で対応できるため、アプリケーションのコードを変更する必要はありません。
1. X-Frame-Optionsヘッダーを設定する
X-Frame-Optionsは、ブラウザに対して「このページをiframeに埋め込んでよいかどうか」を指示するHTTPレスポンスヘッダーです。クリックジャッキング対策として最も普及している方法です。
設定値は以下の2つが実用的です。
・DENY: すべてのiframe埋め込みを拒否する。自サイト内でもiframeに表示できなくなる
・SAMEORIGIN: 同一オリジン(同じドメイン)からのiframe埋め込みのみ許可する。自サイト内での利用は維持したい場合に使う
Apacheでの設定例です。
# Apache: httpd.conf または .htaccess # mod_headers が有効であること Header always set X-Frame-Options "SAMEORIGIN"
nginxでの設定例です。
# nginx: server ブロック内に追記 add_header X-Frame-Options "SAMEORIGIN" always;
設定後、curlコマンドで正しく反映されているか確認しましょう。
# レスポンスヘッダーの確認 curl -sI https://example.com/ | grep -i x-frame-options # 出力例: X-Frame-Options: SAMEORIGIN
2. Content-Security-Policy(CSP)のframe-ancestorsを設定する
CSP(Content-Security-Policy)のframe-ancestorsディレクティブは、X-Frame-Optionsの後継にあたる、より柔軟な制御方法です。特定のドメインからのiframe埋め込みだけを許可するなど、細かい制御が可能です。
# Apache: すべてのiframe埋め込みを拒否 Header always set Content-Security-Policy "frame-ancestors 'none'" # Apache: 同一オリジンのみ許可 Header always set Content-Security-Policy "frame-ancestors 'self'" # Apache: 特定ドメインのみ許可 Header always set Content-Security-Policy "frame-ancestors 'self' https://trusted.example.com"
# nginx: すべてのiframe埋め込みを拒否 add_header Content-Security-Policy "frame-ancestors 'none'" always; # nginx: 同一オリジンのみ許可 add_header Content-Security-Policy "frame-ancestors 'self'" always;
X-Frame-OptionsとCSP frame-ancestorsの両方が設定されている場合、CSP frame-ancestorsが優先されます。現在はCSP frame-ancestorsの方が推奨されていますが、古いブラウザへの対応としてX-Frame-Optionsも併記しておくのが安全です。
3. JavaScriptによるフレームバスティングを補助的に使う
フレームバスティング(Frame Busting)は、JavaScriptで自身のページがiframe内に読み込まれていないかをチェックし、iframe内であればトップフレームに移動させるテクニックです。
# フレームバスティングの基本パターン(JavaScript) # if (window.top !== window.self) { # window.top.location = window.self.location; # }
ただし、この方法には限界があります。攻撃者がsandbox属性付きのiframeを使ったり、JavaScriptを無効化する手法で回避できるケースがあるためです。あくまでHTTPヘッダーによる対策の補助として位置づけてください。
中小企業でも今日からできること
クリックジャッキング対策はHTTPヘッダーを1行追加するだけで完了するため、Webアプリケーションの改修が不要です。情シス1人体制の中小企業でも、サーバー設定で即座に導入できます。
| 対策 | 内容 | コスト |
|---|---|---|
| X-Frame-Optionsの設定 | Apache/nginxの設定ファイルに1行追加。自社サイトがiframeに埋め込まれることを防止する | 無料 |
| CSP frame-ancestorsの設定 | X-Frame-Optionsとの併記で、新旧ブラウザの両方に対応する | 無料 |
| WordPress管理画面の保護 | wp-login.phpやwp-admin/にX-Frame-Options: DENYを設定し、管理画面のiframe埋め込みを完全に遮断する | 無料 |
| レンタルサーバーの.htaccess設定 | Apache環境のレンタルサーバーなら.htaccessでX-Frame-Optionsを設定できる。サーバー管理者権限がなくても対応可能 | 無料 |
| 設定の定期確認 | curlコマンドやブラウザの開発者ツールで、ヘッダーが正しく出力されているか四半期ごとに確認する | 無料 |
レンタルサーバーを使っている場合は、.htaccessファイルに以下の2行を追加するだけで対策が完了します。
# .htaccess に追記 Header always set X-Frame-Options "SAMEORIGIN" Header always set Content-Security-Policy "frame-ancestors 'self'"
WordPressの場合は、テーマのfunctions.phpに以下のコードを追加する方法もあります。
# functions.php に追記するPHPコード # send_frame_options_header() 関数が wp-login.php で自動実行されるが # フロントページにも適用する場合は以下を追加 # add_action('send_headers', function() { # header('X-Frame-Options: SAMEORIGIN'); # });
よくある誤解と注意点
【注意】「うちのサイトはiframeを使っていないから関係ない」は誤解
クリックジャッキングで問題になるのは「自サイトがiframeを使っているかどうか」ではなく、「自サイトが他者のページにiframeで埋め込まれるかどうか」です。X-Frame-OptionsやCSP frame-ancestorsが未設定の場合、どのサイトでも勝手にiframeに埋め込むことができてしまいます。自サイトでiframeを使っていなくても、対策は必須です。
【注意】「HTTPS化しているから安全」ではない
HTTPS(SSL/TLS)はデータの暗号化と通信相手の認証を行う仕組みであり、クリックジャッキングとは防御する領域が異なります。HTTPS化されたサイトであっても、X-Frame-Optionsが設定されていなければiframeへの埋め込みは制限されません。HTTPSとクリックジャッキング対策は、それぞれ別のレイヤーで必要なセキュリティ対策です。
【注意】「X-Frame-Options: ALLOW-FROM」は非推奨
X-Frame-Optionsには「ALLOW-FROM」という設定値がかつて存在しましたが、現在の主要ブラウザ(Chrome・Firefox・Edge等)ではサポートされていません。特定ドメインからのiframe埋め込みだけを許可したい場合は、CSPのframe-ancestorsディレクティブを使用してください。

本記事のまとめ
クリックジャッキングは、透明なiframeを使ってユーザーのクリック操作を乗っ取る攻撃手法です。ユーザー自身が物理的にクリックしているため被害に気づきにくく、アカウント設定の変更や不正な購入操作など、1クリックで実行できるあらゆる操作が悪用されるリスクがあります。
防御の基本は、HTTPレスポンスヘッダーで自サイトのiframe埋め込みを制限することです。X-Frame-OptionsとCSP frame-ancestorsの2つを併記することで、新旧ブラウザの両方に対応した防御を構築できます。
| 脅威 | 対策 | 優先度 |
|---|---|---|
| iframeによるページの埋め込み | X-Frame-Options: SAMEORIGIN の設定 | 最優先 |
| 古いブラウザでの対策漏れ | CSP frame-ancestors との併記 | 最優先 |
| 管理画面の操作乗っ取り | 管理画面にX-Frame-Options: DENY を設定 | 高 |
| JavaScript無効環境での攻撃 | HTTPヘッダーによるサーバー側制御(JS依存しない) | 高 |
| 設定の形骸化 | curlコマンドによる定期的なヘッダー確認 | 中 |
クリックジャッキングと併せて押さえておきたいCSRFやXSSの対策については、本サイトの関連記事で詳しく解説しています。Webアプリケーションの脆弱性は複数の攻撃手法が組み合わされることも多いため、横断的に理解しておくことが重要です。
ApacheやnginxのHTTPヘッダー設定やWebサーバーの基本的なセキュリティ強化については、姉妹サイトLinuxMaster.JPで詳しく解説しています。
自社サイト、iframe埋め込みへの対策は済んでいますか?
クリックジャッキングはHTTPヘッダー1つで防げる攻撃ですが、対策していないサイトはまだまだ多いのが現状です。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。


コメント