セキュリティ

クリックジャッキングとは?iframe悪用への注意

クリックジャッキングは、利用者が見ているボタンと、実際にクリックされる要素がすり替わる攻撃です。透明なiframeを重ねるだけで成立し、気づきにくいのが特徴です。この記事では仕組みと、ページを共有する際の注意点を解説します。

クリックジャッキングの仕組み

クリックジャッキングは、攻撃者が用意したページの上に、標的サイトを透明なiframeで重ねて表示する手口です。利用者は手前の見えるボタンを押しているつもりが、実際には背後の標的サイトの要素をクリックしてしまいます。

「Clickjacking」は「クリック」を「ハイジャック(乗っ取る)」する造語です。見た目と操作対象がずれるため、利用者の意図しない操作(設定変更や承認など)を実行させられる恐れがあります。

どんな被害につながるか

クリック一つで完了するような重要操作ほど狙われます。ログイン済みの状態で標的サイトを開いていると、利用者本人の権限で操作が走るため危険です。

具体的には次のような被害が想定されます。いずれも「自分が押したつもりのないボタンが押される」ことから生じます。

  • 意図しない設定変更や、公開・承認ボタンの押下
  • SNSのフォローやシェアなどを勝手に行わせる
  • カメラやマイクなどの許可ダイアログを誤って承認させる
  • 決済や送信といった取り消しにくい操作の実行

よくあるNG例と安全な直し方

クリックジャッキングでは、「検索に出さない」と「見られないようにする」を混同しないことが重要です。noindexやrobots.txtは検索エンジンへの指示であり、アクセス制限そのものではありません。

安全に共有するには、誰に見られると困るかを先に決め、URL共有だけで足りるのか、認証や期限が必要なのかを選びます。共有相手と機密度が決まったら、URLのみ・パスワード・メール認証・会社ドメイン認証のどれで渡すかを選びます。

  • NG: 機密情報入りHTMLを認証なしURLで共有し、noindexだけで安心する
  • OK: パスワード・メール認証・会社ドメイン認証で閲覧者を絞る
  • NG: テスト用APIキーや社内URLをHTML内に残したまま渡す
  • OK: 公開前に外部送信先、秘密情報、フォーム送信先を確認する

基本の対策:埋め込みを制御する

クリックジャッキングは「自サイトを他人のページのiframeに重ねられる」ことが前提です。そこで、埋め込み自体を許可しない設定が基本対策になります。

サーバ側でX-Frame-Optionsヘッダや、CSPのframe-ancestorsディレクティブを使い、誰がこのページを枠内に埋め込んでよいかを宣言します。原則として外部からの埋め込みを拒否し、必要なら信頼できる出所だけを許可します。

確認・対策の手順

自分のページが埋め込み可能な状態かどうかは、設定を確認すればわかります。次の流れで点検と対策を進めましょう。

  1. 対象ページのレスポンスヘッダにframe制御の指定があるか確認する
  2. 指定がなければX-Frame-OptionsかCSPのframe-ancestorsを追加する
  3. 原則は外部からの埋め込みを拒否し、必要な出所だけ許可する
  4. 重要操作には確認ステップを設け、一度のクリックで完了しないようにする
  5. 設定後、別ドメインのページから実際に埋め込めないことを確かめる

共有ページでの注意点

レビュー用に作ったHTMLを共有する場面では、そのページ自体に重要操作が少ないため被害は限定的なことが多いです。とはいえ、フォームや承認ボタンを含むモックを共有する場合は、埋め込み制御を意識しておくと安心です。

ギガサイト便ではHTMLをドロップして即共有でき、確認段階のページを関係者だけに見せたいときはURLのみ・パスワード・メール認証・会社ドメイン認証から閲覧範囲を選べます。広く晒さず関係者に限定すること、そして埋め込まれて困る要素を含むページではframe制御を併せて考えることが、現実的な備えになります。

よくある質問

クリックジャッキングとXSSは違いますか?

違います。XSSはページ内で攻撃者のスクリプトが実行される問題です。クリックジャッキングはスクリプトを注入せず、透明なiframeで重ねて利用者のクリック対象をすり替える攻撃で、視覚的なトリックが中心です。

X-Frame-OptionsとCSPのframe-ancestorsはどちらを使うべきですか?

新しく対応するならCSPのframe-ancestorsがより柔軟で推奨されます。古い環境への配慮としてX-Frame-Optionsを併用する構成もあります。どちらも外部からの埋め込みを制限する目的で使います。

対策できているか確認する方法はありますか?

別ドメインに用意したテストページから、対象ページをiframeで読み込んでみると確認できます。frame制御が効いていれば枠内に表示されず空白になります。レスポンスヘッダの内容を直接確認する方法もあります。

確認用に共有するだけのページでも対策は必要ですか?

重要操作を含まない静的な確認ページなら優先度は下がります。ただしフォーム送信や承認ボタンを含むモックなら意識すべきです。あわせて、見せる相手を関係者に絞っておくと万一の影響を抑えられます。

noindexを設定すれば認証は不要ですか?

不要ではありません。noindexは検索結果への表示を抑えるための指定で、URLを知っている人の閲覧を止める仕組みではありません。閲覧者を制限したい場合は認証が必要です。

関連記事

セキュリティ

XSSとは?共有HTMLで気をつけるリスクの基礎

AIが書き出したHTMLや外部から受け取ったコードを共有する機会が増えるほど、意図しないスクリプト混入のリスクも高まります。XSSの基本的な仕組みと、HTMLを他者に渡す際に気をつけるべきポイントを、わかりやすく整理した入門記事です。

5分で読める
セキュリティ

共有HTMLのフォーム送信先・データの扱いを確認する

共有するHTMLにフォームが含まれているとき、その入力がどこへ送られるか把握していますか。テンプレート流用やAI生成では送信先が意図しない場所のままのことがあります。共有前にフォームの送信先とデータの扱いを確認する方法を解説します。

5分で読める
「セキュリティ」の記事をもっと見る →