Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06

[Martin Thomson <[e-mail]>]

The way that browsers are moving here is to partition space based on the top-level browsing context.  That is, the cookie store for requests to A made by B is different to the cookie store for requests to A made by C.  This is governed by browser policy and there are some exceptions for a bunch of legacy reasons, but I believe that there is general agreement that the desired end state is isolation.  The current state is what enables web-based tracking and other abuses.  Moving to partitioned storage should reduce the need for server-based mechanisms.

See https://github.com/privacycg/storage-partitioning for more on this.

That said, you can't rely on clients maintaining any isolation based on a prefix, so if your goal is to prevent C from using B's token, it's probably not wise to put it in a cookie.  Not all clients will understand the prefix and enforce it, even if some do.

On Tue, Sep 8, 2020, at 10:58, Paolo Argentieri wrote:
> Hi Mark,
> Thanks. I understand that adding new features to cookies is a complex 
> process and I welcome an alternative solutions to the use case below.
> AFAIK, for all practical purposes, Secure HttpOnly cookies are the only 
> client side secure persistent store available to web apps today.
> The "__Host-" Prefix does not seem to provide what's needed.
> 
> Consider this use case:
> - (A) : REST Web Service hosted in Acme.com
> - (B) : Web App hosted in Globex.com, issues fetch requests to (A)
> - (C) : Web App hosted in Contoso.com, issues fetch requests to (A)
> - One user agent accessing both Web Apps (B) and (C)
> 
> Step 1: User navigates to (B), (B) connects to (A) and receives a 
> Secure, HttpOnly cookie (B-A-AccessToken).
> Step 2: User navigates to (C), (C) connects to (A) and receives a 
> Secure, HttpOnly cookie (C-A-AccessToken).
> 
> In this use case, we want the user to explicitly grant (C) access to 
> (A), and not hijack the existing (B-A-AccessToken) cookie.
> The solution, that can be implemented today, is for the server (A) to 
> keep track to what "origin", (B) or (C), the AccessToken cookie was 
> first issued to.
> 
> The issue here is that when (C) issues fetch calls to (A) both 
> (B-A-AccessToken) and (C-A-AccessToken) cookies are sent. E.g.
> 
> //JavaScript hosted in (C)
> fetch(uriOf(A)/resource123,
>             {
>                 credentials: "include",  //NOTE: Both (B-A-AccessToken) 
> and (C-A-AccessToken) cookies are included but only (C-A-AccessToken), 
> the one matching the request header Origin: (C), is considered by the 
> server. 
>                 mode: "cors"
>             }) .then(...
> 
> Ideally, the user agent would know to only send the (C-A-AccessToken) 
> cookie in the first place.
> My original proposal is an attempt to define a backwards compatible 
> "Origin locked" cookie: conformant user agent would not set or send 
> "Origin locked" cookies that don't "match" the Origin request header.
> 
> Regards,
> Paolo
> 
> -----Original Message-----
> From: Mark Nottingham <[e-mail]> 
> Sent: Monday, September 7, 2020 12:50 AM
> To: Paolo Argentieri <[e-mail]>
> Cc: [e-mail]
> Subject: Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06
> 
> 
> 
> Hi Paolo,
> 
> Are you familiar with the __Host prefix?[1]
> 
> Describing what you want to do in relation to it might be more helpful.
> 
> Also, from a procedural standpoint, we have a pretty high bar for 
> adding new features to cookies in the current work; the proposals that 
> are current in-scope needed to gain consensus for inclusion before we 
> started the work. So, we'd need to see some pretty strong support for a 
> new feature, given the state of the work.
> 
> Cheers,
> 
> 1. 
> https://urldefense.com/v3/__https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html*the-host-prefix__;Iw!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olqMau0eg$ [httpwg[.]org]
> 
> 
> 
> > On 5 Sep 2020, at 12:44 pm, Paolo Argentieri <[e-mail]> wrote:
> > 
> > Hi all, first post here.
> > 
> > I'd like to propose a new "__Origin-" cookie prefix with "origin locked" semantic.
> > While it is possible to implement these cookies today, standardized user agent support would add a layer of optimization and security.
> > 
> > The cookie name begins with prefix "__Origin-" followed by the domain that served the parent page (the origin) and, optionally, a name postfix. Example:
> > 
> > Set-Cookie: __Origin-apps.contoso.com-accessToken=12345; Secure; HttpOnly; SameSite=None
> > 
> > A conformant user agent would ensure that the cookie will have been set with a "Secure" attribute and the domain following "__Origin-" matches the request Origin.
> > In addition, a conformant user agent would not send an "__Origin-" cookie if the domain in the cookie name does not match the Origin, excluding port.
> > 
> > A server should ignore "__Origin-"  cookies whose name doesn't match the Origin request header. This combination yields cookies that are pinned to a specific origin thus well suited to roundtrip session ids or JWTs (immune to XSS session hijacking attack).
> > 
> > Regards,
> > Paolo Argentieri
> > 
> > 
> 
> --
> Mark Nottingham   
> https://urldefense.com/v3/__https://www.mnot.net/__;!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olZcXJkUg$ [mnot[.]net]
> 
> 
>