クリックジャッキングとは？仕組みや被害例、対策を初心者向けにわかりやすく解説【図解付き】

利用者をだまして、本人が意図していないボタンやリンクをクリックさせる攻撃だよ。

偽物を押させるというより、見えているボタンの裏側に、本物のWebページのボタンを隠しておくイメージだね。

そう。透明にした正規サイトの画面を、攻撃者の用意したページに重ねて表示するんだ。

透明な紙で考えてみよう。

机の上に、次のような申込書が置かれているとしよう。

• 商品を購入する
• アカウントを削除する
• 設定を変更する

その申込書の上に、透明な紙を重ねる。

透明な紙には、

「ここを押すとプレゼントがもらえます」

と書かれているよ。

そう。でも、そのボタンの位置が、下にある「商品を購入する」ボタンと重なっていたらどうなる？

それがクリックジャッキングの基本的なイメージだよ。

クリックジャッキングは、一般的に次のような流れで行われるよ。

そこが重要なんだ。利用者がすでに正規サイトへログインしている状態を悪用することがある。

そう。正規サイトから見ると、ログイン済みの利用者が自分でボタンを押したように見える場合があるんだ。

あるWebページの中に、別のWebページを表示するためのHTML要素だよ。

例えば、Webページ内に次のようなものを埋め込む場合に利用されるよ。

• 動画
• 地図
• 広告
• 決済画面
• 外部のWebコンテンツ

その通り。iframe自体は悪いものではないよ。

そう。正規サイトを自分のページ内に表示し、透明化や位置調整によって利用者をだますんだよ。

Webサービスの機能によって異なるけれど、例えば次のような被害が考えられるよ。

ログインしていること自体が危険というわけではないよ。ただし、クリックジャッキングではログイン状態が悪用されることがあるんだ。

ブラウザが正規サイトのCookieなどを使って、ログイン済みの状態でページを表示する場合があるからだよ。

例えば、利用者がSNSへログインしたまま罠のページを開いたとする。

罠のページ内に正規SNSの設定画面が読み込まれ、ボタンが透明な状態で重ねられていると、利用者のクリックによって設定変更が実行される可能性があるよ。

そう。それがクリックジャッキングの厄介なところだよ。

クリックジャッキングは、UIリドレッシングの代表的な手法として扱われるよ。

UIとは、利用者が操作する画面やボタンなどを意味し、

リドレッシングには、「着せ替える」「外見を変える」といった意味がある。

つまりUIリドレッシングは、

本来の操作画面を別の見た目で覆い、利用者に誤った操作をさせる手法

ということだね。

どちらも利用者をだます攻撃だけど、目的や仕組みが違うよ。

基本的にはその整理でいいよ。

どちらも、ログイン中の利用者に意図しない処理を実行させる可能性がある点は似ているね。

クリックジャッキングは、利用者のクリックを利用する。CSRFは、攻撃者が用意したリクエストを正規サイトへ送信させる攻撃だよ。

XSSは、脆弱なWebページへ不正なスクリプトを埋め込み、利用者のブラウザ上で実行させる攻撃だよ。

攻撃者側のページで正規サイトを重ねて表示することで成立する場合があるよ。

Content Security Policyの略で、Webページで許可するコンテンツや動作を制限する仕組みだよ。

CSPのframe-ancestorsディレクティブを使うと、そのWebページをどのサイトのフレーム内に表示してよいかを指定できる。

例えば、どのサイトからもフレーム内に表示させたくない場合は、次のように設定する。

Content-Security-Policy: frame-ancestors 'none';

同じオリジンのページからだけ表示を許可する場合は、次のように設定する。

Content-Security-Policy: frame-ancestors 'self';

特定のサイトだけに埋め込みを許可することもできるよ。

そう。クリックジャッキングは対象ページをフレーム内に表示することへ依存するため、埋め込みを制限することが有効なんだ。

frame-ancestorsの方が新しく、柔軟に許可先を設定できるよ。

重要な操作では、複数の対策を組み合わせた方がいいよ。

例えば、次の操作を行う前にパスワードを再入力させるんだ。

• アカウント削除
• 送金
• パスワード変更
• メールアドレス変更
• 権限変更

そう。IPAも、重要な処理の直前に再度パスワード認証を行う方法を対策の一つとして示しているよ。

確認画面を設ける場合も、単純に同じ位置の「はい」ボタンを追加するだけではなく、操作内容を利用者が確認できる設計が重要なんだ。

補助的な対策として、CookieのSameSite属性が役立つ場合があるよ。

クリックジャッキングは、利用者だけで完全に防ぐのが難しい攻撃だよ。基本的にはWebサイト側の対策が重要なんだ。

それでも、利用者側では次の点を意識できるよ。

• 不審なWebサイトを開かない
• 不自然にクリックを求めるページを警戒する
• ブラウザを最新の状態にする
• 利用後は重要なWebサービスからログアウトする
• 重要な操作後は履歴や設定を確認する
• 不審な広告やゲーム画面をむやみに連打しない

そうだね。ただし、見た目だけで見抜けないこともあるから、サイト運営者側で根本的な対策を行う必要があるよ。

そのサイトが本当にフレーム表示を必要としないなら、それでもいいよ。

ただし、Webページを別のサービスへ正式に埋め込む必要がある場合、全面的に禁止すると正常な機能まで利用できなくなるよ。

例えば、次のようなケースだよ。

• 社内ポータルへの埋め込み
• 決済サービスとの連携
• パートナー企業のページへの表示
• Webシステム内での画面統合

「透明なフレームを重ね、利用者に意図しないクリックをさせる」という仕組みだと覚えよう。

その理解でバッチリ。利用者の目に見える画面と、実際のクリック対象をずらすのが特徴だよ。

そう。試験では、その違いを整理したうえで、CSPのframe-ancestorsやX-Frame-Optionsが対策になることを覚えておこう。