セキュリティ

クリックジャッキングを含むHTMLを共有するときのリスクと対策

自社のHTMLが攻撃者にiframeで悪用されるクリックジャッキングリスクは、適切なHTTPヘッダーとCSS設計の見直しで大幅に軽減できます。リスクの仕組みを理解した上で、AI生成HTMLに特有の注意点と具体的な対策を整理しました。

なぜ危ないのか

クリックジャッキング攻撃は「UIレッドレッシング」とも呼ばれ、正規のウェブページを透明なiframeで覆い、ユーザーが別のものをクリックしていると思い込ませます。AI生成HTMLが社内の承認フォームや設定画面の場合、攻撃者はそのページを透明にして自分のサイトに重ね、被害者に無意識に承認・設定変更をさせます。

AI生成HTMLには時折、レイアウト調整のためのオーバーレイ要素が含まれます。これらが意図せずクリックジャッキングの構造を作り出すことがあります。見た目では判断できないため、CSSの検査とHTTPヘッダーの確認が必要です。

  • 相手がログインなしで開ける状態か確認する
  • PCとスマホで最低1回ずつ表示を確認する
  • 内部情報・個人情報・不要な外部送信が残っていないか見る
  • レビュー期限と修正時の差し替え方を決めておく

ソースで見る場所

CSSで`position:fixed`または`position:absolute`が設定された要素のうち、`width:100%`・`height:100%`・`top:0`・`left:0`を持つものを探します。これらがフルスクリーンオーバーレイになっていないか確認します。AIが生成するモーダルやローディング画面がこのパターンに当てはまることが多いです。

JavaScriptに`document.body.style.pointerEvents`や特定要素の`pointerEvents`をmanipulateするコードがある場合も確認します。pointer-eventsをoffにした要素は視覚的に存在するのにクリックが素通りするため、意図しないUXや攻撃の素地になりえます。

  • HTML内の外部script・form action・iframeを確認する
  • APIキーやトークンらしき文字列がないか検索する
  • 画像・CSS・JSのパスが公開後も解決できるか見る
  • noindexと認証を混同せず、必要なら両方設定する

安全に共有する設定

ギガサイト便でHTMLを共有する際は、管理画面でセキュリティヘッダーの設定を確認します。`X-Frame-Options: DENY`が設定されていれば、共有したHTMLが第三者のサイトにiframeで埋め込まれることを防げます。この設定はHTMLの中身に関わらず有効です。

パスワード認証に加えて会社ドメイン認証を使うと、そもそも認証を通過した社員・パートナー以外にはコンテンツが見えないため、クリックジャッキングの対象となる不特定多数へのアクセスを遮断できます。認証の多重化はクリックジャッキング以外の脅威にも有効な多層防御です。

  • HTML内の外部script・form action・iframeを確認する
  • APIキーやトークンらしき文字列がないか検索する
  • 画像・CSS・JSのパスが公開後も解決できるか見る
  • noindexと認証を混同せず、必要なら両方設定する

再発防止ルール

AI生成コードのCSSレビューで「フルスクリーンオーバーレイの有無」を確認するステップを設けます。正規の用途(モーダル・ドロワー)か、不要な残存物かを判断し、不要なオーバーレイはコードから削除します。特にローディングスピナーが除去されずに残ることが多いです。

本番公開のためのHTMLを生成する際は、AIへのプロンプトに「X-Frame-Options対策のためのframe-busterスクリプト(`if(top !== self) top.location = self.location`)をheadに追加すること」と指示します。これはHTTPヘッダーの代替手段として機能し、古いブラウザ環境でも有効です。

  • HTML内の外部script・form action・iframeを確認する
  • APIキーやトークンらしき文字列がないか検索する
  • 画像・CSS・JSのパスが公開後も解決できるか見る
  • noindexと認証を混同せず、必要なら両方設定する

よくある質問

frame-busterスクリプトとX-Frame-Optionsヘッダー、どちらを優先すべきですか?

HTTPヘッダーのX-Frame-Optionsをサーバー側で設定するのが第一選択です。frame-busterスクリプトはJavaScriptが無効な環境では動作しないため補助的な手段です。可能であれば両方を設定することをお勧めします。

自社のHTMLがクリックジャッキングに使われているか発見する方法はありますか?

完全な検出は難しいですが、Google Search Consoleで自社URLへの外部からの埋め込み参照を確認できる場合があります。また`Referer`ヘッダーのログを解析すると、iframeで読み込んでいる外部サイトのURLが記録されているケースがあります。

モーダルやサイドドロワーを使うHTMLでもクリックジャッキング対策は必要ですか?

モーダルを含むページが攻撃対象になりやすいです。特に「確認」「送信」「承認」のようなボタンがあるページはクリックジャッキングの標的になりやすいため、X-Frame-Optionsの設定は必須と考えてください。

関連記事

セキュリティ

http混在を含むHTMLを共有するときのリスクと対策

http混在を含むHTMLを共有した場合のリスクを把握し、適切な対処法を選びたい方向け。ブラウザによる表示ブロックや通信傍受のリスクを具体的に示しながら、修正・代替策・共有設定の3つの観点から対策を解説します。

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

XSSを含むHTMLを共有するときのリスクと対策

XSSが含まれる可能性のあるHTMLを共有するリスクを把握し、適切な対策を講じたい担当者向け。被害シナリオ、コードレベルの修正方法、CSPによる軽減策、再発防止の仕組みづくりを段階的に解説します。

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

オープンリダイレクトを含むHTMLを共有するときのリスクと対策

オープンリダイレクトを含むHTMLを外部共有するリスクを理解し、修正判断と対策を迷わず行いたいチームリーダー・開発者向け。フィッシング被害の具体的なシナリオと、許可リスト実装・URL認証による二段階対策を解説する。

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

社外レビュー前にクリックジャッキングを検出するチェックリスト

社外レビュー用にHTMLを共有する前にクリックジャッキングリスクを洗い出したい方向け。ソース検索からブラウザ開発者ツールを使った検証手順まで、見落としがちな確認項目を網羅し、安全な公開判断ができるようになるチェックリストを提供します。

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

クリックジャッキングを防ぐAIプロンプトと公開前スキャン

AIプロンプトの書き方を工夫してクリックジャッキングの原因となるコードをそもそも生成させたくない方向け。プロンプト制約の具体文例と、生成済みHTMLを素早くスキャンするコマンドを組み合わせた二段構えの防止策を解説します。

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