Tabnabbing と clickjacking: 見えない UI 攻撃

tabnabbing が実際にやっていること

タブはバックグラウンドに回っていても自分で再読み込みできます。 これは脆弱性ではなく、意図して用意されたブラウザの機能です。 メールの通知を待っている人には、タブが前面になくても 知らせる必要があるからです。Tabnabbing はまさにここに付け込みます。

攻撃の流れはこうです。無害そうなページを開いたまま 別のタブに移ると、最初のページのスクリプトは Page Visibility API やフォーカスイベントのハンドラで切り替えを 検知し、数分ほど待ちます。そのうえでタイトル、ファビコン、 HTML をまとめて差し替えます。さっきまで記事だったものが、 Google、Microsoft、GitHub のログイン画面のような見た目になります。

戻ってくると、自分で開いたはずのタブに見覚えのある ログイン画面が出ています。アドレスバーの URL はもとのページのままですが、わざわざ確認する人はほとんどいません。 ログインフォームは入力内容を攻撃者に送ったあと、本物の Google にリダイレクトするので、二度目の入力で「さっきは入力をしくじっただけかな」 で済ませてしまうわけです。

clickjacking: ひとつのボタン、二つの正体

Clickjacking はまた違う種類の UI トリックです。攻撃者は正規のページ（たとえば パスワード変更ページや「送金」フォーム）を見えない iframe に読み込ませ、その上に「クリックで賞品ゲット」といった 魅力的なおとりを重ねます。利用者はおとりをクリックしているつもりですが、 実際のクリックは下にある本物のボタンに届きます。 ブラウザから見ると正しく承認されたクリックなので、そのまま受け付けてしまいます。

定番のパターンは、iframe に入れた Facebook のいいねボタンの上にゲーム要素を重ねるやり方です。被害者は、 見たこともないページに知らないうちに「いいね」を押させられます。 下のボタンが OAuth 同意画面の「Confirm」や分散型アプリの「Send transaction」になると話はぐっと深刻で、どちらも実際の攻撃で 何度も悪用されてきました。

ここで守りを固める側はサイト運営者です。X-Frame-Options ヘッダや Content-Security-Policy の frame-ancestors は、信頼されたサイトを他のサイトが iframe に取り込むのを禁止します。大手のプラットフォームは きちんと対処しています。ヘッダを設定していないサイトは 引き続き悪用される余地がありますし、比較的新しい Web3 系のサイトには歴史的にここの抜けが目立ってきました。

window.opener を使う reverse tabnabbing

これと近い手口に reverse tabnabbing があります。新しく開かれたタブは window.openerを通じて、自分を開いたページにアクセスできます。攻撃者が 自分のリンクをあなたのサイトに紛れ込ませられれば、新しい タブの中からもとのページをリダイレクトできてしまいます。 あとで戻ってくると、さっきまでいたはずのサイトを模した フィッシングクローンに着地している、という流れです。

対策は外部リンクすべてにrel="noopener"を付けることで、最近のブラウザは新しいタブで開くリンクには 自動で適用しています。これで古典的な経路はふさがれますが、 フォーラムやユーザー投稿型のサイトでは、投稿を雑にレンダリングしている限り 脆弱なままです。

これらの攻撃が消えない理由

UI 攻撃を長持ちさせている性質は三つあります。第一に、 技術的なルール違反というよりも、ほとんどが慣習に対する さりげない逸脱でしかありません。タブの中身を書き換えるのも、iframe を埋め込むのも、ブラウザにとっては正当な機能です。第二に、 利用者が自分では意識して監視していない視覚的・状況的な習慣に 依存しています。そもそも自分が慣習に従っていることにすら 気づいていないからです。

第三に、コストがほとんどかかりません。tabnabber は数十行ほどの JavaScript を載せた HTML ファイル一枚で成立します。攻撃者は何十もの亜種を並行して デプロイし、malvertising や SEO の悪用と組み合わせていて、ひとつが検知されてもほぼ痛手になりません。

今日からできる対策

緩和策の大部分はブラウザとサイト運営者の側で担当しています。残りの穴は、利用者側のちょっとした習慣でふさげます。

1. 1

   予期しないタブのログイン画面を疑う

   覚えのないタイミングでタブが突然ログインを求めてきたら、 そのまま閉じてください。サービスはブックマークから開き直すのが安全です。
2. 2

   ログインフォームでは毎回 URL を確認する

   アドレスバーは tabnabbing でも書き換えられません。見慣れないドメインの「Gmail ページ」は、それだけで偽物だと判断できます。
3. 3

   セッションは短めに保つ

   タブを開きっぱなしにしている時間が長いほど、書き換えの チャンスを与えてしまいます。機密性の高いサービスでは、 長時間バックグラウンドに置かれたタブは避けるのが無難です。
4. 4

   重要な操作は専用の隔離セッションで

   OAuth の同意、トランザクションの署名、アカウント連携を行うときは、 他に何も並行して動いていないセッションで実行してください。 横で操作されうる二つ目のタブが存在しなければ、既知の UI トリックはまとめて無力化できます。