Re: [webauthn] Missing specification on rpId validations when calling credentials.get() from a different origin (#1731)

Thanks. This is touched on in the definition of [WebAuthn Relying Party](https://w3c.github.io/webauthn/#webauthn-relying-party):

>[...] Communication between the two components MUST use HTTPS or equivalent transport security, but is otherwise beyond the scope of this specification.

and in [§13.4.4. Attestation Limitations](https://w3c.github.io/webauthn/#sctn-attestation-limitations):

>[...] For example, such an attacker could use malicious code injected into [Relying Party](https://w3c.github.io/webauthn/#relying-party) script. The [Relying Party](https://w3c.github.io/webauthn/#relying-party) must therefore rely on other means, e.g., TLS and related technologies, to protect the [attestation object](https://w3c.github.io/webauthn/#attestation-object) from [man-in-the-middle attacks](https://tools.ietf.org/html/rfc4949#page-186).

but we don't explicitly mention that other ways of injecting malicious script are equally potent threats.

We do however state in [§13. Security Considerations](https://w3c.github.io/webauthn/#sctn-security-considerations) that

>[...] the [[FIDOSecRef]](https://w3c.github.io/webauthn/#biblio-fidosecref) document provides a security analysis which is overall applicable to this specification. [...]

which in turn lists the threat:

>[**FIDO Client Corrpution**](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-security-ref-v2.0-id-20180227.html#threats-to-the-user-device-fido-client-and-relying-party-client-applications) _[sic!]_
>Attacker gains ability to execute code in the security context of the FIDO Client.    
>
>**Consequences:** Violation of [SA-4]. _[Where SA-4: The computing environment on the FIDO user device and the and applications involved in a FIDO operation act as trustworthy agents of the user.]_
>
>**Mitigations:** When the operating environment on the FIDO user device allows, the FIDO       Client should operate in a privileged and isolated context under [SA-2] to protect       itself from malicious modification by anything outside of the Trusted Computing       Base.

So we do _technically_ cover it, but it's certainly a bit buried.

---

I don't think we explicitly state anywhere in WebAuthn itself the assumption that "the client acts as a trustworthy agent of the user". Perhaps we should, or perhaps that is a fundamental implicit assumption in all web standards? As has been discussed in other issues, an attacker who can execute arbitrary code in the client can already bypass any security boundaries WebAuthn is meant to enforce without breaking WebAuthn itself.

Anyway, perhaps we should also extend the above security considerations to recommend using [Content Security Policy](https://content-security-policy.com/) or similar techniques to reduce the risk of malicious code injection.

This statement in [§13.4.4. Attestation Limitations](https://w3c.github.io/webauthn/#sctn-attestation-limitations) may also need revision as it does not appear to consider the attack described here.

>Under the assumption that a [registration ceremony](https://w3c.github.io/webauthn/#registration-ceremony) is completed securely, and that the [authenticator](https://w3c.github.io/webauthn/#authenticator) maintains confidentiality of the [credential private key](https://w3c.github.io/webauthn/#credential-private-key), subsequent [authentication ceremonies](https://w3c.github.io/webauthn/#authentication-ceremony) using that public key credential are resistant to [man-in-the-middle attacks](https://tools.ietf.org/html/rfc4949#page-186).

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


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

Received on Thursday, 12 May 2022 17:14:10 UTC