Re: [webauthn] Hybrid transport opt-out and ability for verifiable proof (#2349)

I think the attack seems legitimate, but I'm not sure it would be solved by, for example,  adding a `transport` value to `clientDataJSON`.

The attack begins with overriding `navigator.credentials.get`, so the victim's client isn't involved at all in the WebAuthn ceremony. I don't know in detail how the [`hybrid` transport](https://fidoalliance.org/specs/fido-v2.2-ps-20250714/fido-client-to-authenticator-protocol-v2.2-ps-20250714.html#sctn-hybrid) works, but from skimming the spec it looks to me like the "authenticator" end still acts purely in the authenticator role, and it's still the "client" end that acts as the client, which in particular includes constructing the `clientDataJSON` value that the authenticator signs. In the attack scenario, this role is performed by the attacker's server, so the attacker can simply lie about any or all of the values in `clientDataJSON` (indeed, it already lies about `origin` which is why the attack works in the first place).

So considering that the first step of the attack is to sidestep the WebAuthn API altogether, I don't think there's much we can do within the WebAuthn API to prevent or detect it. I don't know how the `hybrid` transport protocol could be strengthened to prevent it either - I'd say the authenticator would need to somehow authenticate both the relay server and the client at the other end, but that probably means you can't have the inline setup on first use. But somehow locking down the initial pairing procedure seems to me like one of few possible ways to prevent this.

But yeah, I don't think we could add any signed attribute in WebAuthn that would make the attack preventable or detectable, since the attacker completely sidesteps WebAuthn and is in full control of what's being signed.

I can currently think of only one workaround that'll work with no spec or implementation changes: require attestation, and only allow authenticators that are known to not support the `hybrid` transport (i.e., only built-in, USB and NFC). That would ensure that the victim's client can't be sidestepped in this way, since the attacker won't have connectivity to the authenticator.

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2349#issuecomment-3443724672 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 24 October 2025 15:28:38 UTC