LASSIC Media らしくメディア
クリックジャッキングとは｜クリックを盗む手口と対策
Webサイトで「同意する」や「送信」のボタンを押したとき、自分が押したつもりのボタンと、実際に反応したボタンが食い違っていたら——。クリックジャッキングは、まさにそうした「クリックのすり替え」を、利用者に気づかせないまま起こす攻撃です。画面には見慣れたサイトが表示されていても、その上に透明な罠が重ねられている、という手口になります。
クリックジャッキング（clickjacking）は、利用者のクリックを本来とは別の操作へ誘導し、意図しない処理を実行させる攻撃手法です。入力欄に不正な文字列を送り込むタイプの攻撃とは違い、利用者自身の正当なクリックを逆手に取る点に特徴があります。この記事では、発注者やプロジェクトマネージャー、これからWeb開発に関わる方に向けて、クリックジャッキングの仕組みと被害、そして開発・発注の現場でおさえておきたい対策を整理していきます。
クリックジャッキングとは何か
クリックジャッキングとは、正規サイトの見た目の上に、利用者からは見えない別のページを重ね、クリックの行き先をひそかにすり替える攻撃です。「クリック（click）を乗っ取る（hijacking）」という言葉を組み合わせた呼び名で、画面の見せかけを悪用することから「UIリドレス」と呼ばれることもあります。
典型的な流れを追ってみましょう。攻撃者はまず罠のページを用意し、その上に、標的となる正規サイトのページを透明にした状態で重ねて配置します。利用者に見えているのは罠のページ（たとえば「プレゼントを受け取る」ボタンなど）だけですが、実際にクリックが届くのは、手前に重なった透明な正規サイトのボタンのほうです。こうして利用者は、気づかないうちに正規サイト側の操作を実行させられてしまいます。
ここで押さえておきたいのは、正規サイトそのものが書き換えられているわけではない、という点でしょう。表示されているのは本物のページであり、利用者も本物を操作しています。ただ、その本物が透明な状態で罠の上に置かれているために、クリックの意味だけがすり替わる、という構図なのです。
この記事のポイント
- クリックジャッキングは、透明に重ねた別ページで利用者のクリックの行き先をすり替える攻撃です。
- 正規サイトを改ざんせず、利用者自身の正当なクリックと権限を逆手に取る点に特徴があります。
- 防御の中心は、自サイトを他サイトの枠内に表示させない設定（X-Frame-OptionsやCSPのframe-ancestors）です。
なぜ成立するのか（仕組み）
クリックジャッキングが成り立つ背景には、Webページが別のページを「枠」として自分の中に埋め込める仕組みがあります。この埋め込みに使われるのがiframeという要素です。iframe自体は、地図や動画、決済画面などを他サイトから取り込むために広く使われている、正当な部品にすぎません。
問題は、この仕組みが悪用されうる点にあります。攻撃者は標的の正規サイトをiframeで読み込み、CSS（見た目を制御する仕組み）で透明度をゼロ近くまで下げ、事実上見えない状態にします。そのうえで、利用者が思わず押したくなる罠のボタンを、透明なiframeとぴったり重なる位置に配置するわけです。
利用者の目に映っているのは罠のボタンだけです。しかしクリックは、いちばん手前にある透明なiframe——つまり正規サイトのボタンへ吸い込まれます。マウスの位置と、実際に反応する要素とが食い違うこの状態こそ、クリックジャッキングの核心といえるでしょう。応用として、ドラッグ操作を利用して入力欄に文字を引き込ませる手口も知られています。
どんな被害につながるのか
クリックジャッキングは、一見すると「ボタンを一つ押させるだけ」の攻撃に映ります。ところが、その一押しが重い操作に結びつくと、被害は一気に広がるのです。代表的なねらいを整理しました。
| 悪用のねらい | 起こりうること |
|---|---|
| 意図しない設定変更 | プライバシー設定の公開範囲を広げさせる、連携アプリを許可させる |
| なりすまし操作 | SNSのフォローや投稿を、本人の意図とは無関係に行わせる |
| 送金・購入の実行 | ワンクリック決済や送金のボタンを押させ、金銭の被害につなげる |
| 権限の付与 | カメラやマイクの利用許可、外部サービス連携の承認を得る |
いずれのねらいも、利用者本人のログイン状態や権限をそのまま利用して成立する点が共通しています。攻撃者は利用者になりすます必要すらなく、利用者自身に「正規の操作」を行わせてしまうため、サーバ側のログ上は本人の正当な操作と見分けにくいのも厄介なところでしょう。だからこそ、後から気づいても取り返しがつきにくい操作ほど、事前の備えが問われます。
どう防ぐのか（対策）
クリックジャッキングを防ぐ基本は、「自分のサイトのページを、他人のサイトの枠（iframe）の中に表示させない」ことに尽きます。枠の中に表示させなければ、透明に重ねる余地そのものが消えるからです。しかも、その多くはサーバ側の設定だけで実現できます。主な手立てを見てみましょう。
| 対策 | 内容 | 位置づけ |
|---|---|---|
| CSPのframe-ancestors | どのサイトからの枠内表示を許すかを、レスポンスヘッダで指定する | 現在の推奨。細かく制御でき、複数ドメインの指定にも対応 |
| X-Frame-Options | 枠内表示を拒否（DENY）、または同一サイトのみ許可（SAMEORIGIN） | 古くからある方式。対応環境が広く、指定も単純 |
| 重要操作の再確認 | 送金や設定変更の前に、確認画面や再入力のひと手間を挟む | 補助策。一度の押し間違いだけでは完了させない |
軸になるのは、フレーム内表示を制御するヘッダを返すことです。新しく作るシステムならCSPのframe-ancestorsを中心に据え、古い環境も想定するならX-Frame-Optionsを併せて返す構成が現実的でしょう。さらに、送金や退会のような取り返しのつきにくい操作には確認のステップを一つ挟んでおくと、万一すり抜けられても被害を小さく抑えられます。
なお、かつてはJavaScriptで枠内表示を検知して抜け出す「フレームバスティング」という手法も用いられました。ただし迂回されやすいことが分かっており、現在はヘッダによる制御が主流です。JavaScriptだけに頼る守り方は避けたほうがよいでしょう。
発注・開発でおさえる点
クリックジャッキング対策は、個々の開発者の実装テクニックというより、システム全体の方針として織り込むべきテーマです。発注や設計の段階で意識しておきたい点を挙げておきます。
セキュリティ要件に明記する
「クリックジャッキング対策として、枠内表示を制御するヘッダを全ページで返す」ことを、要件定義や設計書に一文でも書き入れておくと、実装の抜け漏れを防ぎやすくなります。とりわけログイン後の操作画面や、設定・決済にかかわる画面は優先して押さえたい箇所でしょう。
既存サイトは現状を点検する
すでに公開しているサイトでは、これらのヘッダが実際に返っているかを確かめるところから始めます。ブラウザの開発者ツールやオンラインの診断で、レスポンスヘッダの中身を確認できるでしょう。抜けていれば、WebサーバやアプリケーションフレームワークのHTTPヘッダ設定で付け足します。
iframe連携がある場合は許可先を絞る
自社サイトを意図して他サイトへ埋め込んでいる（決済画面や地図の提供など）場合は、一律の拒否だとその連携まで動かなくなってしまいます。どのドメインからの埋め込みを許すのかを洗い出し、frame-ancestorsで許可先を列挙する形にすれば、正当な連携を保ちながら守れます。
よくある誤解と勘所
クリックジャッキングは、名前は知られていても中身が誤解されがちなテーマです。代表的なつまずきを表にまとめました。
| よくある誤解 | 実際のところ |
|---|---|
| HTTPSにすれば防げる | 通信の暗号化とは別の話。HTTPSでも枠内表示を制御しなければ成立してしまう |
| 入力値の検証をすれば防げる | 不正な入力ではなく正当なクリックの悪用。入力検証では止められない |
| JavaScriptで抜け出せば十分 | フレームバスティングは迂回されやすい。ヘッダによる制御が土台になる |
| ログインしていなければ無関係 | ログイン中の利用者が主な標的だが、無関係と言い切ることはできない |
勘所をひとことでいえば、クリックジャッキングを「入力の攻撃」ではなく「表示の攻撃」として捉えることに尽きます。防ぐべきは不正な文字列ではなく、自サイトが他サイトの枠に取り込まれてしまう状況そのものです。だからこそ対策も、入力検証ではなく、枠内表示を制御するヘッダへと向かうわけです。この視点を持っておくと、どこに手を打てばよいかが見えやすくなります。
まとめ
- クリックジャッキングは、透明に重ねた別ページで利用者のクリックの行き先をすり替える攻撃である。
- 正規サイトを改ざんせず、利用者の正当なクリックと権限を逆手に取る点に特徴がある。
- iframeによる枠内表示を悪用するため、対策はその表示を制御することに向かう。
- CSPのframe-ancestorsやX-Frame-Optionsを、レスポンスヘッダで返すのが基本。
- 送金や設定変更など重い操作には、確認のステップを挟んで被害を抑える。
よくある質問
クリックジャッキングとXSSはどう違うのですか。
ねらう場所が異なります。XSS（クロスサイトスクリプティング）は、サイトに不正なスクリプトを送り込み、閲覧者のブラウザ上で実行させる攻撃です。一方クリックジャッキングは、スクリプトを注入するのではなく、正規サイトを透明に重ねて利用者のクリックそのものをすり替えます。XSSが「不正な入力の実行」であるのに対し、クリックジャッキングは「正当なクリックの悪用」であり、対策も入力検証ではなく枠内表示の制御へと向かう点が違いになります。
X-Frame-OptionsとCSPのframe-ancestorsは、どちらを使えばよいですか。
これから作るシステムであれば、CSPのframe-ancestorsを軸にすることをおすすめします。許可するドメインを細かく指定でき、より柔軟に制御できるためです。ただし、古いブラウザや一部の環境ではframe-ancestorsが解釈されない場合もあるため、X-Frame-Optionsを併せて返しておくと取りこぼしを減らせます。両方を返しても矛盾はしません。新しい仕組みを主、古い仕組みを補助と位置づけるとよいでしょう。
自社サイトが対策できているかは、どう確認できますか。
まずはレスポンスヘッダを見るのが早道です。ブラウザの開発者ツールを開き、ネットワークのタブでページのレスポンスを選ぶと、返っているHTTPヘッダの一覧を確認できるはずです。ここにContent-Security-Policyのframe-ancestors、またはX-Frame-Optionsが含まれているかを見ます。オンラインのヘッダ診断サービスでも同様に調べられるでしょう。抜けていれば、Webサーバやアプリケーション側の設定で付与する流れになります。
iframeは使わないほうがよいのですか。
iframe自体は、地図や動画、決済画面の埋め込みなどで日常的に使われる正当な部品であり、避けるべきものではありません。問題になるのは、自社サイトが他人のサイトのiframeに勝手に取り込まれてしまう状況です。したがって、iframeの利用をやめるのではなく、自サイトが枠内に表示される条件をヘッダで制御することが本筋になります。自社が提供する埋め込みも、許可先を絞れば正当な連携を保てます。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、Webアプリケーションのセキュリティ要件の整理から設計・実装、公開済みサイトの点検・改修までを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。クリックジャッキングをはじめとする表示まわりの対策でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
出典
- MDN Web Docs「X-Frame-Options」
- MDN Web Docs「CSP: frame-ancestors」
- OWASP Cheat Sheet Series「Clickjacking Defense」
