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

[Paolo Argentieri <[e-mail]>]

Hi Martin,
Thanks for the link. The "Top-level origin" concept is useful in this discussion.

Currently, storing secrets (e.g. bearer token) in httponly cookies seems to be the only practical local store solution for keeping it safe from code injected in a page.
I agree: the server should independently verify cookies origin regardless.

The value added of a "__Origin-" cookie prefix with " top-level origin locked" semantic would be:
- Backwards compatible. 
- Conformant user agents would add a layer of security and enable scalability:
 1) E.g., "Set-Cookie" header would be accepted only if FQDN matches the FQDN of top-level browsing context origin
         Set-Cookie __Origin-FQDN; Secure; HttpOnly;

 2) Cookie "__Origin-FQDN" would be included in the request only if FQDN matches the FQDN of top-level browsing context origin
     Since only the FQDN matching cookies would be included in the request, it enables scalability when many "top-level browsing context web apps" interact with same web service.

I'll admit that this proposal is not particularly elegant. If a new cookie prefix is just not in the future the specification, let me know!

Thanks,
Paolo


-----Original Message-----
From: Martin Thomson <[e-mail]> 
Sent: Monday, September 7, 2020 7:00 PM
To: [e-mail]
Subject: Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06



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://urldefense.com/v3/__https://github.com/privacycg/storage-partitioning__;!!AD8y5q2f9OQ!9fBZA4O8qjQRnLM_a4XDijQ0wA2PnI5P8McKlDY14BMZOzsvB537FmlWMjQ37lWCguA6Aco$ [github[.]com] 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-i
> etf-httpbis-rfc6265bis.html*the-host-prefix__;Iw!!AD8y5q2f9OQ!4Ou-7lGJ
> NdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_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]
> 
> 
>