- From: Emil Lundberg via GitHub <noreply@w3.org>
- Date: Tue, 28 Oct 2025 14:07:08 +0000
- To: public-webauthn@w3.org
@ntrojanowska Unfortunately that would not prevent this attack. The main part of the attack happens _before_ the authenticator generates the response: the malicious client sets the RP ID to a different value than the one for the page the user navigated to. That causes the authenticator to sign over the "correct" RP ID and `clientDataJSON.origin`, so even if the result was sent directly back to the RP, the RP would accept the assertion with no indication that anything went wrong. And no, making the authenticator connect directly to the RP to _initiate_ the ceremony also wouldn't help, it would make things worse: then a malicious actor wouldn't even need to trick the victim into loading a malicious webpage, instead they could just ping the server to make it pop an authentication request on the victim's authenticator. For example, the Swedish BankID system had this exact vulnerability and there's been _lots_ of organized fraud using variants of this attack. WebAuthn's requirement that the ceremony is mediated through a client on the user's device is a critical component of preventing these kinds of attacks (and is precisely why the attack in this thread begins with sidestepping the WebAuthn API altogether). -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2349#issuecomment-3456673327 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 28 October 2025 14:07:09 UTC