クリックジャッキングとは？起きるパターンと対策法

クリックジャッキングとは？起きるパターンと対策法

#セキュリティ#Web開発#脆弱性対策

クリックジャッキングは、正規サイトを透明なiframeで隠し、利用者に気づかれず意図しない操作をさせる攻撃です。 対策は明快で、自サイトを他サイトのフレーム内に埋め込ませない設定を入れられているかで決まります。

クリックジャッキングとは

クリックジャッキング：攻撃者のページに正規サイトを透明化したiframeで重ね、利用者が別の要素を操作しているつもりで、実際には正規サイト上のボタンを押させる攻撃です。 自サイトが他サイトのフレーム内に埋め込めることが根本原因になります。

利用者は攻撃者ページの「無料」ボタンなどをクリックしているつもりで、裏側では正規サイトの操作を実行します。 設定の変更、購入や送金の確定、権限の許可など、クリック1つで完了する重要操作が狙われます。 利用者は自分の意思で操作しているように見えるため、被害に気づきにくく、事後の追跡も難しくなります。

クリックジャッキングが起きるパターン

典型的な弱点は次のとおりです。

  • レスポンスにX-Frame-OptionsやCSPのframe-ancestorsを設定しておらず、任意のサイトから埋め込める
  • クリック1回で完了する重要操作があり、追加の確認を挟んでいない
  • ドラッグ操作やキー入力を誘導し、フォームの値まで気づかせず入力させる（応用手口）
  • SNSの「いいね」やフォローなど、1クリックで完了するソーシャル操作を誘発される
  • 管理画面や決済画面など、埋め込みを想定していないページで対策が抜けている

共通するのは「自サイトが第三者のページに重ねられ、利用者が意図しないクリックをさせられる」という点です。

対策法

原則は「自サイトを他サイトのフレーム内に表示させない」ことです。

  • レスポンスヘッダにCSPのframe-ancestorsを設定し、埋め込みを許可するオリジンを限定する。これが本命の対策になる
  • 併せてX-Frame-Options（DENYまたはSAMEORIGIN）を設定し、古いブラウザにも対応する
  • 送金や設定変更など重要操作では、再認証や確認ステップを挟んで単一クリックでの完了を避ける
  • 埋め込みが必要な正規の利用先だけをframe-ancestorsで明示的に許可する
  • CookieにSameSite=LaxまたはSameSite=Strictを設定し、クロスサイトのフレーム内で認証Cookieが送られる範囲を狭める（補助策）

ヘッダによるフレーム制御は設定だけで広く効くため、まずこれを全ページに適用するのが最優先です。 重要操作への確認ステップは補助として重ね、費用対効果の高い順序で対策を積みます。 SameSite=LaxやSameSite=Strictはクロスサイトの埋め込みには補助的に効きますが、同一サイト（same-site）の別オリジンからの埋め込みには効かず、SameSite=Noneも防御になりません。

Rails での事例

Rails は既定で全レスポンスに X-Frame-Options: SAMEORIGIN を付けるため、素の状態ではクリックジャッキングに耐性があります。 事故が起きるのは、パートナーサイトへの埋め込み対応などをきっかけに、この防御を外してしまうときです。

# 危険：埋め込み要件に対応するため、ヘッダごと消してしまう
class WidgetsController < ApplicationController
  after_action { response.headers.delete("X-Frame-Options") }
end

これでは特定パートナーだけでなく、あらゆるサイトからの埋め込みを許してしまいます。 埋め込みを許可したい相手が決まっているなら、CSP の frame-ancestors で許可先を列挙します。

# config/initializers/content_security_policy.rb
Rails.application.config.content_security_policy do |policy|
  policy.frame_ancestors :self, "https://partner.example.com"
end

frame-ancestors を指定した場合、対応ブラウザではこちらが優先されます。 埋め込みが不要なアプリケーションであれば、既定の SAMEORIGIN を消さないことがそのまま対策になります。 削除やヘッダ書き換えのコードが混ざっていないか、X-Frame-Options を対象にリポジトリを検索して確認します。

まとめ

クリックジャッキング対策の要点を整理します。

  • 根本原因は「自サイトが他サイトのフレーム内に埋め込めること」。利用者は攻撃者ページのボタンを押しているつもりで、裏側の正規サイトの操作を実行している
  • 本命の対策はレスポンスヘッダ。CSPのframe-ancestorsで埋め込みを許可するオリジンを限定し、X-Frame-Options（DENY / SAMEORIGIN）も併記して古いブラウザに備える
  • Railsは既定でX-Frame-Options: SAMEORIGINを全レスポンスに付ける。事故は、パートナーサイトへの埋め込み対応などでこのヘッダを削除したときに起きる
  • 埋め込みを許す相手が決まっているなら、ヘッダごと消すのではなくframe_ancestors :self, "https://partner.example.com"のように列挙する
  • 送金や設定変更のような重要操作には再認証や確認ステップを挟み、1クリックで完了しないようにする
  • CookieのSameSite=LaxまたはSameSite=Strictはクロスサイトの埋め込みを制限する補助策になるが、same-siteの別オリジンには効かないため、フレーム制御ヘッダの代わりにはならない

ヘッダによるフレーム制御は設定だけで広く効くため、まず全ページに適用するのが最優先です。 点検はX-Frame-Optionsを対象にリポジトリを検索し、削除や書き換えのコードが混ざっていないかを見るところから始まります。

関連して読める記事

利用者のブラウザを経由して意図しない操作をさせるという点で、CSRFと同じ系統の攻撃です。 CSRFがリクエストを偽装するのに対し、クリックジャッキングは本物の画面を利用者自身に操作させる点が違います。 どちらもブラウザ側の境界に依存した防御であり、その境界を意図的に緩めるCORSの設定と並べて理解すると全体像がつかめます。 1クリックの重要操作を守る話は、XSSでスクリプトを実行された場合の被害想定とも重なります。

CSRF（クロスサイトリクエストフォージェリ）とは？起きるパターンと対策法

CSRF（クロスサイトリクエストフォージェリ）の仕組みと起きるパターン、CSRFトークンとSameSite Cookieを軸にした対策を整理します。Railsで検証を外してしまう skip_before_action の罠と、React（TypeScript）からのトークン送信ヘッダの組み込み方を、危険なコードと安全な書き方の具体例で示します。

2026年7月23日

CORS設定ミスとは？起きるパターンと対策法

CORS設定ミスの仕組みと起きるパターン、許可オリジンのホワイトリスト管理を軸にした対策を整理します。rack-cors でアンカーのない正規表現が部分一致になり example.com.attacker.net まで通る危険例と、完全一致で列挙する正しい設定、ワイルドカードと credentials の併用禁止を具体的なコードで示します。

2026年7月25日

XSS（クロスサイトスクリプティング）とは？起きるパターンと対策法

XSS（クロスサイトスクリプティング）の仕組みと3つの型、混入しやすいパターン、そして出力時のエスケープを軸にした対策を整理します。React（TypeScript）の dangerouslySetInnerHTML と Rails（ERB）の raw / html_safe を題材に、危険なコードと安全な書き方を具体的なコード例で示します。

2026年7月22日
この記事をシェア