パスワードマネージャへのクリックジャッキング攻撃に対して、いま私たちが出来ること

こんにちは、TRUSTDOCKのよもぎたです。GASでSlackbot作ってるおじさん化が激しい最近の私ですが、本来の所属は情報セキュリティ部です。たまにはそれっぽい記事も書いてみたいと思います。

概要

この記事は、こちらのツイートで話題の「1PasswordやBitwardenやiCloud等のパスワードマネージャーへのクリックジャッキング攻撃」について、いま私たちが出来ること、私が理解できたことをまとめた記事です。

この記事はありとあらゆる銀河系で[1] もっとも無保証で、筆者は読者がこの記事に記載された内容をもとに行ったアクションとその結果ついて、あるいはアクションを行わなかったこととその結果について、一切責任を取りません。ご納得いただけない方は、ただちにお引き返し下さい。
この記事の内容は公開時点（2025年08月21日時点）のものとなります。
ちょっと堅苦しくて書きたいわけではないのですが、こういう話題なので一応。

注釈

[1] 遠い昔、遥か彼方の銀河系を含みます。[2]
[2] この注釈は何？ → 私がSTAR WARSファンなのでやってみたかったお遊びです。

本記事執筆時点の筆者のステータスは次の通りです。

• 元のレポート：DOM-based Extension Clickjacking: Your Password Manager Data at Riskをざっと斜め読みした
• 読んだ箇所は主に次の通りです
  • Key Information
  • Mitigation
  • Recommendations for Users
  • Conclusion

まずお伝えしたいこと

ChromiumベースのWebブラウザ、Google ChromeやMicrosoft Edgeを使っているならば、入力補助機能があるブラウザ拡張の設定を 「ブラウザ拡張のアイコンをクリックしたときのみ有効化する」設定 にすることをお勧めします。これは完全な対策ではなくて、緩和策です。これを実施して注意して運用すればいくらかの被害の軽減は見込めそうです。

手順

ご案内できるOSはWindows11です。Mac、iOS/iPadOS、Androidなどなど他はごめんなさい。
ご案内できるブラウザはGoogle ChromeとMicrosoft Edgeです。他はごめんなさい。

Google Chrome

1. Chrome右上の「拡張機能」ボタン（パズルのピースみたいなアイコン）をクリックします
2. ブラウザにインストールされているブラウザ拡張の一覧が表示されます
3. その中から、対象のブラウザ拡張（例えば、1Passwordのブラウザ拡張）をピン止めします
4. 「ブラウザ拡張」ボタンの左側に、「ブラウザ拡張のアイコン」が表示されます（ややこしいな）
5. 「ブラウザ拡張のアイコン」を右クリックし、メニューから「サイトデータの読み取りと変更～」→トグルスイッチから「拡張機能をクリックしたとき」を選択します。
6. できればChromeの再起動、少なくとも入力補助を用いるページの再読み込みをします。

Microsoft Edge

操作手順はGoogle Chromeとほぼ同じなので省略させてください。細かい文言が違うくらいです。

何が変わるの？

設定変更前は自動で表示されていた入力候補（認証情報やクレカ情報）が自動で表示されなくなります。

「認証情報やクレカ情報を入力したい！入力するぞ！」というときは、

1. 使いたいブラウザ拡張機能（パスワードマネージャなど）のボタンをクリックします
2. ページの再読み込みを促されるので、再読み込みします

というステップが増えます。これで、たとえばCookieを受け入れる/拒否するボタンにオーバーレイされたクレカ情報入力フォームをクリックしても、ブラウザ拡張を有効にするまではクレカ情報は入力されないはずです。

あのー

この対策をやっておけば万全なんですか？

いいえ。
残念ながら、そもそもこれ、緩和策です。

攻撃者は日々巧妙化し、人間の注意力には限界がある、というのが基本ですし、それを持ち出すまでもなく、正規サイトが攻撃され本来の入力フォームの上に攻撃者の入力フォームがオーバーレイされる、というシナリオはありうると感じました。サイトの正規のコンテンツ改竄より発覚しにくい手段としてありうるのではないか、と考えています。まーその時は入力補助の有無に関係なく、高度なペイメントアプリケーションの改ざん、になる気もしますが。

この緩和策のソースは？

元のレポートのKey Informationの6つ目に下記の記載があります。これが元ネタです。

For Chromium-based browser users it is recommended to configure site access to "on click" in extension settings. This configuration allows users to manually control autofill functionality.

チケット争奪戦の時困るんですけど？

はい、わたしも悩みました。私はよくグランドシネマサンシャイン池袋の週末のチケットをとるのにアクセス集中でSorryページに飛ばされて何度も何度もリロードしてます。
でも、グラシネ池袋はじめ多くのシネコンのチケット予約の決済情報の入力は、争奪になる座席確保の後なので、たぶん大丈夫なのでは。

シネコン以外は...サイトの作り、申し込みフロー次第なじゃないでしょうか。

ブラウザ拡張をサイト単位（ドメイン単位）で許可するのは？

いわゆるホワイトリストですね。現時点での個人的な意見としては、お勧めしません。
理由は、攻撃者が正規のサイト（ドメイン）の脆弱性（XSSやSubdomain takeover）を悪用して攻撃してくる可能性が元のレポートで指摘されています。このとき、Webブラウザが正規サイト（ドメイン）と判定してしまったら終わりです。仕様、実装がどうなっているかは、私は知らないし調べてもいません。

その他、分かっていることの整理

パスワードマネージャに気を付ければよいの？

いいえ。
入力補助機能を提供するすべてのブラウザ拡張で注意する必要がある、緩和策を実行した方が良い（やらないよりは幾分マシ）と考えておくべきです。

元のレポートでは、暗号通貨関連の入力補助のブラウザ拡張などが例に挙げられていました。その方面は全く知らないので、どんなものがあるか分かりませんが...

Conclusionに但し書き的にothers DOM-manipulating extensions will be vulnerable (password managers, crypto wallets, notes etc. ) と書かれています。

クレカ情報入力のときに気を付けておけばいいの？

いいえ。
認証情報など、他のパスワードマネージャに格納されている情報全て、窃取される恐れがあります。

クレカの3Dセキュアは？

クレカ情報入力後にページ遷移しますので、その時点で情報は窃取されてしまっている、と考えるべきかと思います。不自然なページ遷移をトリガーにカード会社に停止を依頼する、などの緩和策が考えられますが、カード会社がどこまで対応してくれるかは未知数です。

攻撃はどんな実装なの？

元のレポートのページに詳細が解説されています。
これについて踏み込んだ記事にする予定はありません。

哲学的な問題

「入力補助」というのはどうなの？「DOM/サイトデータの読み取りと操作」じゃないの？というのは私も思いましたが、分かり易さ優先でこの表現にしました。

最後に

それにしても、よくこんなこと思いつくなー、よく気づくなー、と感心しちゃいました。
いや、これほんとリサーチャーの方が公表してくれて良かったな、と思います。

最後までお読みいただきありがとうございました。