パスキーでフィッシング(remoteDesktopClientOverride)する仕組みとその防御について

Last updated at 2026-10-15Posted at 2026-10-15

本検証はすべて筆者のローカル環境で完結していて、防御機構の理解を目的とした解説です。
remoteDesktopClientOverrideについて既知の問題点を実際に動かしながら解説するものです。

パスキーでもフィッシングできる場合がある

周知のとおり、パスキーはフィッシング耐性がある認証方式です。

フィッシング耐性を実現する機構の1つとして、ブラウザがWebAuthnリクエスト中のrpIdと、ブラウザがアクセスしているオリジンをチェックしています。
これによって、中間者経由でのパスキー認証ができないのでフィッシングされません。

逆に考えると、ブラウザにrpIdとオリジンのチェックを緩めさせることができれば、フィッシングが可能になるということです。

ブラウザの制約を意図的に緩める仕組みがある

背景、リモートブラウザ分離

リモートブラウザ分離でパスキー認証をする場合、これから説明する事情のため、ブラウザによるrpIdとオリジンのチェックを緩める必要性があります。

リモートブラウザ分離は、Webブラウジングを手元の端末ではなく、クラウド上の遠隔ブラウザで実行する仕組みです。
ユーザーから見ると、ローカルブラウザのタブにリモートブラウザがあるマトリョシカのような状態になります。

リモートブラウザ環境でパスキー認証するために

このリモートブラウザ環境でパスキー認証することを考えます。
下記の環境を前提とします。

RPexample.comがパスキー認証を要求すると、リモートブラウザremote.exampleがWebAuthnリクエストを中継し、ローカルブラウザがrpIdexample.comでのWebAuthnリクエストを受け取ります。

しかし、ローカルブラウザにとってのオリジンはhttps://remote.example(リモートブラウザをホストしている環境)です。
WebAuthnでは、rpIdが呼び出し元オリジンのドメインと一致しない（またはその親ドメインでない）場合、ブラウザは認証器を呼び出す前にSecurityErrorで要求を拒否します。

これはパスキーのフィッシング耐性を支える仕組みですが、この仕組みによってリモートブラウザ環境でパスキー認証ができなくなります。

フィッシング耐性を緩める仕組み

そのため、リモートブラウザ環境でパスキー認証をするためにはブラウザのフィッシング耐性を意図的に緩める必要があります。
標準仕様はまだ確定していませんが、ChromiumではremoteDesktopClientOverrideというWebAuthnクライアント拡張を実装しています。

WebAuthnリクエストのextensionsに次のように指定するものです。

navigator.credentials.get(
{publicKey:{
  rpId:'example.com',
  challenge:...,
  extensions:{
    remoteDesktopClientOverride:{        // <--- コレ
        origin:'https://example.com',
        sameOriginWithAncestors:true
    }
  }
}})

この拡張が付いているWebAuthnリクエストを受け取ったChromeブラウザは、指定された値にオリジンを上書きします。

具体例として、ブラウザがアクセスしているオリジンがhttps://remote.exampleの状態で、remoteDesktopClientOverride: https://example.comを受け取ると、オリジンがhttps://example.comに上書きされます。

オリジンが上書きされることによって、ブラウザはドメイン不一致によるSecurity Errorを出さなくなります。

認証器への認証依頼も上書き後のオリジンをベースに行われますので、問題なくパスキー認証を行うことができます。

攻撃者による`remoteDesktopClientOverride`の活用

すでにお気づきかもしれませんが、この拡張を利用できるのはリモートブラウザだけではありません。

正規のユースケースではリモートブラウザがremoteDesktopClientOverrideを付与する一方で、攻撃時は中間者がremoteDesktopClientOverrideを付与することでフィッシングを成立させようとします。

攻撃者がremoteDesktopClientOverrideを活用するリスクはExplainerでも触れられています。

By design, this extension breaks the WebAuthn security model that guarantees non-phishability of the credentials.

以降では、攻撃者がremoteDesktopClientOverrideを活用することを前提として、Chromiumに備わっている防御機構について説明し、最終的には実際にパスキーのフィッシングを試します。

Chromiumの防御機構

無条件でremoteDesktopClientOverrideを受け入れてしまうと、パスキーのフィッシングが簡単に成立してしまいます。それでは困るので、ChromiumはremoteDesktopClientOverrideを受入れるオリジンを制限しています。

本記事を執筆した2026年10月時点で、下記の条件でremoteDesktopClientOverrideを受入れるようです。Googleのドキュメントと実機で確認しています。

組織管理下にあるブラウザを使用していて、組織のユーザーでブラウザにログインしていること。Googleのドキュメントにおけるaffiliated userは上記の状態を指している。

This policy only applies to affiliated users.

ブラウザのポリシーでWebAuthenticationRemoteDesktopAllowedOriginsを設定していること

Any origin configured in this policy can make WebAuthn requests for Relying Party IDs (RP IDs) that it would normally not allowed to be able to claim.

組織管理下にあるブラウザ、というのはGoogle Workspace等で管理されているブラウザです。
「Google Workspaceで管理」というのはイメージがわかない方も一定数いらっしゃると思うので管理画面のスクリーンショットを載せておきます。（私も今回の検証で初めて使いました、、）
ブラウザを組織管理下に置くことで、ブラウザの拡張機能やポリシー等の状態を管理できるようになるようです。

上記のような組織管理下にあるブラウザを使っている前提で、さらにポリシーWebAuthenticationRemoteDesktopAllowedOriginsを設定する必要があります。

WebAuthenticationRemoteDesktopAllowedOriginsは現時点ではGoogle Workspaceの管理コンソールから設定できないようですので、ローカルマシン上で設定する必要があります。ローカルマシン上の所定の場所にjsonを置くだけです。

上記3つの条件を満たすと、パスキーに対してもフィッシングが可能になります。

考えられる攻撃

パスキーのフィッシング耐性を部分的に破壊する機能なだけあって、厳重に保護されています。
しかし、現状ではWebAuthenticationRemoteDesktopAllowedOriginsをローカルマシン上で設定する仕様です。
管理コンソールでのみ設定できたほうが安全だと思うのですが、何らかの事情があるのでしょう。

ローカルマシンでWebAuthenticationRemoteDesktopAllowedOriginsを設定する仕様のため、組織管理下にあるブラウザを使用しているユーザーにローカルポリシーを編集させることで、パスキーに対してフィッシングが可能になります。

念のため書きますが、remoteDesktopClientOverrideを利用してフィッシングが可能になることは仕様や実装の不備ではありません。

攻撃者のいいなりになってポリシーを編集してしまうユーザーのリテラシーが原因です。

navigator.credentials.get()ではrpIdを指定しないことが可能ですが、指定しない場合でも攻撃は成立します。rpIdを指定しない場合には、オリジンの実効ドメインがrpIdとなる仕様であり、remoteDesktopClientOverrideはオリジンを上書きするためです。

実際にパスキーをフィッシングする

調べたら実際にやってみたくなるのが人の性ですので、ローカル環境で実践してみました。
下記のような構成を用意しました。
中間者evil.localはブラウザとRPの間に入って、すべての通信を中継しつつ、WebAuthnリクエストにremoteDesktopClientOverrideを付与します。
RPにはWebAuthn.ioをidp.service.local上でホストしたものを使用しています。
ブラウザは組織管理下のChromeで、ポリシーWebAuthenticationRemoteDesktopAllowedOriginsでevil.localを許可しています。このポリシーは、攻撃者のいいなりになったユーザーが設定してしまう前提です。

ローカルマシンに設定しているポリシー

$ cat /etc/opt/chrome/policies/managed/evil-policy.json 
{
  "WebAuthenticationRemoteDesktopAllowedOrigins": [
    "https://evil.local"    # 中間者を許可リストに入れている
  ]
}

パスキーをフィッシングする

evil.localにアクセスします。中間者がブラウザとRPidp.service.localとの間に入って通信を中継しているので、直接RPにアクセスした場合と同じ画面が表示されます。
URLバーを見ると、中間者（フィッシングサイト）にアクセスしていると確認できます。

下記にフィッシングサイトでパスキー認証するGIFを載せます。
ユーザーがアクセスしているサイトはevil.localですが、idp.service.localの鍵でパスキー認証できています。
(GIF中で、「idp.service.localでセキュリティキーを使う」というポップアップが出ています)

当然ながら、認証器にevil.localの鍵は入っていません。idp.service.localの鍵でパスキー認証しています。

認証器の鍵一覧にevil.localのものがないことを確認

$ ykman fido credentials list | grep -e "idp.service.local" -e "evil.local"
Enter your PIN: 
73704dea...    idp.service.local               Phishing_test           Phishing_test

ブラウザのコンソールからcredentials.get()を確認すると、
中間者によって、credentials.get()のextensionにremoteDesktopClientOverrideが付与されていることが確認できます。

中間者がremoteDesktopClientOverrideを付与したcredentials.get()

{
  "publicKey": {
    "challenge": "...",
    "extensions": {
      "remoteDesktopClientOverride": {        // <--- コレ
        "origin": "https://idp.service.local",
        "sameOriginWithAncestors": true
      }
    }
  },
}

ChromeはremoteDesktopClientOverride: https://idp.service.localを受け取ると、オリジンをhttps://idp.service.localとしてパスキー認証します。

これによって、中間者が存在していてもパスキー認証が可能になり、フィッシングが成立します。

まとめと感想

WebAuthnクライアント拡張remoteDesktopClientOverrideを利用すると、パスキーでフィッシングが可能になる理由を説明して、実演しました。

フィッシングが可能になる拡張だけに、remoteDesktopClientOverrideが適用される条件は厳しいものとなっています。Chromeが組織管理下にあって、かつWebAuthenticationRemoteDesktopAllowedOriginsポリシーが設定されている必要があります。

remoteDesktopClientOverrideはChromium独自拡張ですが、標準仕様としてremoteClientDataJSONの策定が進められています。

remoteClientDataJSONを無条件で適用してしまうと、パスキーのフィッシング耐性が弱まってしまうので、remoteClientDataJSONを適用できるオリジンを何らかの方法で制限する必要があるはずです。
Chromiumは組織管理ブラウザかつポリシー設定で制限をしていましたが、remoteClientDataJSONの保護はどのように規定されるのでしょうか。

今後どのように仕様が定まっていくか注目していきたいです。