From 424a7a50a93343d02b0a0dd2bb1ee689bdf65732 Mon Sep 17 00:00:00 2001 From: Dominic Battre Date: Tue, 14 Feb 2017 16:15:46 +0100 Subject: [PATCH] Permit silently storing PSL matched credentials --- index.html | 42 +++++++++++++++++++++++++++--------------- index.src.html | 23 +++++++++++++++++++++-- 2 files changed, 48 insertions(+), 17 deletions(-) diff --git a/index.html b/index.html index 5d04045..bb58fe6 100644 --- a/index.html +++ b/index.html @@ -1431,7 +1431,7 @@

Credential Management Level 1

-

Editor’s Draft,

+

Editor’s Draft,

This version: @@ -2909,10 +2909,21 @@

of a credential by comparing the registerable domains of the credential’s [[origin]] with the origin in which get() is called. That is: credentials saved on https://admin.example.com/ and https://example.com/ MAY be offered to users when get() is called from https://www.example.com/.
  • MUST NOT offer credentials to an origin in response to get() without user mediation if the credential’s - origin is not an exact match for the calling origin. That is, Credential objects for https://example.com would not be - returned directly to https://www.example.com, but could be + origin is not an exact match for the calling origin. That is, Credential objects for https://example.com/ would not be + returned directly to https://www.example.com/, but could be offered to the user via the chooser. +
  • MAY store credentials without user mediation when store() is called if the credential was + retrieved via a user mediated get() from a + PSL-matched domain and new domain is still PSL-matching the original + domain for which the credentials were stored. +
    A user stores a credential for https://www.example.com/ on + their computer. This credential is synced via the browser’s syncing + technologies to the user’s phone. The user visits https://m.example.com/. The browser may provide the stored + credential to https://m.example.com/ in a user mediated way + due to the Public Suffix List [PSL]. After that the website can call store() and the browser may silently store a + second credential or a reference that allows https://m.example.com/ to retrieve the credential without user + mediation in the future.

    PasswordCredentials further mitigate the risk of data leakage by never exposing the [[password]] slot directly to a page’s JavaScript, but only allowing its submission to a same-origin server-side endpoint via fetch().

    @@ -2943,7 +2954,7 @@

    Therefore, Nested browsing contexts and other environments like Workers [WORKERS] cannot receive or store Credential objects; the user - agent MUST reject promises generated by calls to get() and store() with a SecurityError when + agent MUST reject promises generated by calls to get() and store() with a SecurityError when called from a context which is not a top-level browsing context.

    See the algorithms defined in §4.1.1 Request a Credential and §4.1.2 Store a Credential for details.

    6.4. Insecure Sites

    @@ -2956,7 +2967,7 @@

    (as discussed in §6.1 Cross-origin Credential Leakage.

    6.5. Script Injection

    If a malicious party is able to inject script into an origin, they could - (among many other things you wouldn’t like) overwrite the behavior of store() to steal a user’s credentials as they’re written into the credential store.

    + (among many other things you wouldn’t like) overwrite the behavior of store() to steal a user’s credentials as they’re written into the credential store.

    Authors SHOULD mitigate the risk of such attacks by properly escaping input and output, and add layers of defense in depth by setting a reasonably strong Content Security Policy [CSP] which restricts the origins from @@ -2965,11 +2976,11 @@

    7. Privacy Considerations

    7.1. Timing Attacks

    -

    If the user has no credentials for an origin, a call to get() will resolve very quickly indeed. A malicious +

    If the user has no credentials for an origin, a call to get() will resolve very quickly indeed. A malicious website could distinguish between a user with no credentials and a user with credentials who chooses not to share them.

    This could allow a malicious website to determine if a user has credentials - saved for particular federated identity providers by repeatedly calling get() with a single item in the providers array. The risk is mitigated + saved for particular federated identity providers by repeatedly calling get() with a single item in the providers array. The risk is mitigated by the fact that the user would, sooner or later, be prompted to provide credentials to the site which would certainly raise her suspicions as to its behavior.

    @@ -3072,7 +3083,7 @@

    get() and store() endpoints for their own purposes.

    + simply by allowing extensions to overwrite the get() and store() endpoints for their own purposes.

    9. Future Work

    @@ -3987,10 +3998,10 @@

    4.1.1. Request a Credential
  • 5.3. Credential Selection -
  • 6.1. Cross-origin Credential Leakage (2) (3) -
  • 6.3. Origin Confusion -
  • 7.1. Timing Attacks (2) -
  • 8.3. Browser Extensions +
  • 6.1. Cross-origin Credential Leakage (2) (3) (4) +
  • 6.3. Origin Confusion +
  • 7.1. Timing Attacks (2) +
  • 8.3. Browser Extensions
    • +
  • + MAY store credentials without user mediation when + {{CredentialsContainer/store()}} is called if the credential was + retrieved via a user mediated {{CredentialsContainer/get()}} from a + PSL-matched domain and new domain is still PSL-matching the original + domain for which the credentials were stored. +
    + A user stores a credential for https://www.example.com/ on + their computer. This credential is synced via the browser's syncing + technologies to the user's phone. The user visits + https://m.example.com/. The browser may provide the stored + credential to https://m.example.com/ in a user mediated way + due to the Public Suffix List [[!PSL]]. After that the website can call + {{CredentialsContainer/store()}} and the browser may silently store a + second credential or a reference that allows + https://m.example.com/ to retrieve the credential without user + mediation in the future. +
    + {{PasswordCredential}}s further mitigate the risk of data leakage by never exposing the {{[[password]]}} slot directly to a page's JavaScript, but only allowing its submission to a same-origin server-side endpoint via {{fetch()}}.