Re: Single Trust and Same-Origin Policy v2

On Mon, Mar 27, 2017 at 8:11 PM John Wilander <wilander@apple.com> wrote:

> Hi Jochen!
>
> Thanks for your comments .See my reply inline below.
>
> On Mar 27, 2017, at 1:44 AM, Jochen Eisinger <eisinger@google.com> wrote:
>
> Hey John,
>
> thanks for writing this up!
>
> When reading about the proposal to grant sites from a trust group script
> access to each other, I wonder what your thoughts are on how to protect
> against XSS bugs spreading from a single domain to an entire group of
> origins? It seems that this would go in the opposite direction of
> suborigins, i.e., instead of restricting access even more, it's opening up
> access.
>
>
> Sharing will be allowed if siteA.com claims to own siteB.com AND siteB.com claims
> to be owned by siteA.com. XSS on siteB.com would then have access to
> non-sameSite, non-httpOnly cookies from siteA.com so there are
> implications to XSS.
>    However, fully shared scripting capabilities have not been part of my
> thoughts. I’m mostly interested in sharing of state and simplified
> cross-domain messaging.
>

With the capabilities to serialize / deserialize wasm binaries into indexed
db, this essentially allows for cross domain script, no?

I'm also not sure I understand how the cross domain messaging would be more
simple than the current postMessage model, could you please elaborate on
that?

thank you!
jochen


>
> I believe developers would be OK with the state sharing tradeoff,
> especially since it’s opt-in.
>
>    Regards, John
>
> best
> -jochen
>
> On Sat, Mar 25, 2017 at 1:20 PM Mike O'Neill <michael.oneill@baycloud.com>
> wrote:
>
> Hi John,
>
>
>
> The TPWG (Do Not Track group) discussed something which may be useful for
> this. We have defined a JSON resource at a well-known location (the
> Tracking Status Resource at ./well-known/dnt) which contains a couple of
> relevant properties, the “controller” array and the “same-party” array. See
> https://www.w3.org/TR/tracking-dnt/#status-resource
>
>
>
> The “same-party” property is an array of subresource domain names, each
> one owned by the same company that manages the parent site. The
> “controller” property is an array of urls identifying the companies that
> may be jointly responsible for the site, or more exactly responsible for
> any personal data collected by the site. This corresponds to the European
> legal concept of the “Data Controller”, and the property is an array
> because there can be “Joint” Data Controllers.
>
>
>
> The “same-party” array allow a site to declare the subresource
> “third-party” domains that may be there but are also managed by it, so if a
> user agent implements tracking protection procedures, they could be relaxed
> for these subresources if the user has consented to being tracked by the
> parent site. An obvious example is yimg.com managed by Yahoo when the
> parent site may be yahoo.com, oy youtube.com if the parent is google.com.
>
>
>
> We have also discussed in the past cross-referencing procedures where
> sites would mutually refer to each other using the same-party array, so for
> example when user consent is given for a domain (using the DNT Consent API)
>  it can be automatically assigned to same-parties manged by the same
> controller.
>
>
>
> There may be others in the TPWG interested in the topic so I have copied
> to the list.
>
>
>
> Mike
>
>
>
>
>
>
>
>
>
> *From:* wilander@apple.com [mailto:wilander@apple.com]
> *Sent:* 25 March 2017 00:20
> *To:* Bil Corry <bil@corry.biz>
> *Cc:* public-webappsec@w3.org
> *Subject:* Re: Single Trust and Same-Origin Policy v2
>
>
>
> Hi Bil!
>
>
>
> Thanks for your comments. Please see inline below.
>
>
>
> On Mar 24, 2017, at 3:00 PM, Bil Corry <bil@corry.biz> wrote:
>
>
>
> Hi John,
>
>
>
> Would a third-party service provider contracted by a first-party be a
> first-party resource, or a third-party resource?  For example,
> metrics.apple.com appears to a first-party resource for Apple, but points
> to Adobe Marketing Cloud, which is a third-party service provider.  My
> impression from your description is that only entities owned by the parent
> company with resources embedded on the page would be considered "Single
> Trust" (thus any Apple page that interacts with metrics.apple.com would
> not qualify as Single Trust).
>
>
>
> The notion of a party only goes as deep as domain name in this proposal.
> Which IP address it resolves to is another layer of first and third
> parties, and out of scope. From a user standpoint, the single trust is in
> the organization that takes responsibility for requests and responses.
>
>
>
> To be concrete – metrics.example.com would be considered same party as
> example.com, independent of where the domain owner has decided to route
> the traffic.
>
>
>
> Does it only apply to the HTTP layer?  If I contract with a company to
> create, host, and administer my website, is that Single Trust?  Do I have
> to build the page/site myself?  Do I have to host it myself?  What is the
> difference between paying someone to build and host it for me, and using a
> SaaS solution (which is essentially paying someone for building and hosting
> a solution for me)?  At some point, a third-party has to be involved
> because not many companies operate as a Tier 1 network provider, so I'm
> curious where the trust cutoff is at.
>
>
>
> The cutoff is at domain name ownership. The single trust I’m talking about
> is at the web layer.
>
>
>
> I can see where sites may use Single Trust to convey a stricter security
> boundary to end users, but in practical terms, it may be less secure in
> some instances.  For example, with credit card collection, many sites use
> third-party payment providers to avoid handling credit card data directly.
> If a merchant that currently uses a payment provider switches to using a
> payment gateway, is the customer now more secure having the merchant handle
> the credit card information?  The credit card data ends up at the payment
> provider either way, but now the merchant is also handling it.
>
>
>
> In this case the trustworthy way of doing it is to navigate fully to the
> payment provider where the user can see who he/she is interacting with,
> then back. Note that the site owner can site owners can decide not to opt
> in which means users may decide not to user their services or browsers may
> not autofill card info.
>
>
>
> Another example is any security control provided via a SaaS model - do I
> stop using CloudFlare to protect against DDoS so my page can be Single
> Trust?  Do I stop using reCAPTCHA as a velocity control so my page can be
> Single Trust?  Do I not embed anti-fraud controls into the page so it can
> be Single Trust?  Those controls provide value for end users, yet the
> Single Trust indicator would be off for those pages, making it appear
> otherwise.
>
>
>
> This is a potential issue. Yes, my healthcare provider will have to skip
> third-party DDoS protection the messaging page for if it wants to convey
> Single Trust.
>
>
>
> I do believe web pages can work without third-party dependencies but let’s
> keep drilling into these specific security functions that may be harder to
> achieve with Single Trust. Could they be loaded from the first party?
>
>
>
>    Regards, John
>
>
>
>
>
> On Fri, Mar 24, 2017 at 12:25 PM, John Wilander <wilander@apple.com>
> wrote:
>
> Hi WebAppSec!
>
>
>
> I’m long overdue sending you details on the discussion we started at the
> face-to-face meeting last spring. Here goes …
>
>
>
>
>
> *# Single Trust*
>
>
>
> Users have a few interface signals to decide if they trust a site. There’s
> the URL bar which may show the full URL, the origin, just the host, or the
> name of the organization for sites with EV certificates. The URL bar also
> conveys TLS status with padlocks, warnings, and colors. Recently, Chrome
> and Firefox started to warn about insecure password fields so that’s
> another great signal. Then there's the very subtle mixed passive content
> indicators. I’m sure there’s more.
>
>
>
> We argue that in addition to the above, websites should have the ability
> to tell users that only first party resources are involved in a web page.
> We call this Single Trust – pages where there’s just one entity the user
> has to trust. This makes a lot of sense on pages with password fields and
> credit card fields but I personally would also like the inbox and message
> form where I interact with my physician to be single trust. Pages where you
> submit confidential news tips should also be single trust. And single trust
> would be great for pages where I’m supposed to interact through a plugin
> such as a bridge to a smart card reader.
>
>
>
> Single trust can currently be achieved through a strict CSP but users have
> no way to tell that a site is under such a policy. Ideally, single trust
> should be possible for multiple domains belonging to the same organization
> which is not possible through CSP alone. This leads us to …
>
>
>
>
>
> *# Same-Origin Policy v2*
>
>
>
> Good TLS and the same-origin policy are the cornerstones of web security
> and for a single domain it works just fine. But we end up with tradeoffs
> since the SOP considers apple.com and icloud.com as different as apple.com and
> europa.eu. The most well-known tradeoff is third-party cookies but there
> are tradeoffs for third-party frames, Fetch, workers, and storage. If we
> apply strict rules on third parties we hamper cross-site ecosystems such as
> single sign-on and site integration. If we instead loosen up the rules we
> get cross-site security breakdown and/or third-party tracking.
>
>
>
> We would like to discuss how to technically implement a secure SOP v2 that
> takes domain control/ownership into account. This would allow:
>
>    - Seamless single sign-on across domains with one owner.
>    - Seamless integration across domains with one owner, such as
>    messaging between frames and access to storage.
>    - Much better transparency and rules around third-party resources.
>    - Support for cross-domain Single Trust as per the discussion above.
>
>
>
> Let me know what you think. Thanks!
>
>
>
>    Regards, John
>
>
>
>
>
>