W3C home > Mailing lists > Public > public-webauthn@w3.org > December 2019

Re: [webauthn] Prohibit Create Credential from cross-origin iframes (#1336)

From: Adam Langley via GitHub <sysbot+gh@w3.org>
Date: Mon, 16 Dec 2019 17:30:22 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-566161378-1576517421-sysbot+gh@w3.org>
On the call of 2019-12-11, J.C. requested a Google response on this issue (this is built upon @kenrb's [response](https://www.google.com/url?q=https://github.com/w3c/webauthn/issues/1336%23issuecomment-551880608&sa=D&ust=1576255895844000&usg=AFQjCNHLqK3LbparXDMbfB_D3qApSS8Fqg) above) 

Firstly, we’re not too concerned about similarities to push notifications. The value to the attacker seems significantly smaller: push notifications allow an attacker to induce users to install malware etc, while assertions only allow them to potentially link users across sites. Additionally, the costs to the attacker seem greater: push notifications can be enabled with a single click, while assertions require intrusive UI every time, and for the user to have and touch an authenticator. Another difference is that push notifications are abused by first-party sites while the worry here involves third parties. If third-party embeddings were to start abusing this, first-party sites could always stop embedding them. They might not, but two entities would have to cooperate.  

Secondly, the case where a credential ID is specified seems a little far fetched for mass tracking. The set of possible users will be large and, if you can narrow it down sufficiently to guess at specific credential IDs, then the additional information that knowing the right one gives seems small indeed. This point does not hold for resident credentials, however.

On balance, creating credentials does appear to be something that people legitimately desire from within cross-origin iframes and so we are hesitant to eliminate it. Splitting the feature policy into “create” and “get” is obviously useless when top-level and subresource origins are colluding so would only be useful if delegating only one ability is useful. Our feeling is that detailed API filtering isn’t in the style of Feature Policy, so we lean slightly against this unless the WG doesn’t wish to support “create” initially. There might be cause to prohibit resident credential creation from within cross-origin iframes but we’re concerned that we don’t fully understand the legitimate use cases well enough to have a firm opinion on this. Also, a platform cannot precisely implement such a prohibition with CTAP2 authenticators.

Overall, we’re thus supportive of continuing to allow both operations in cross-origin iframes, when Feature Policy permits, with the possibility of restricting the creation of resident credentials pending site-operator feedback.

GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1336#issuecomment-566161378 using your GitHub account
Received on Monday, 16 December 2019 17:30:24 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:39 UTC