Re: Request for input on Foreign Fetch

On Wed, Jan 27, 2016 at 6:07 AM, Mike West <mkwst@google.com> wrote:
> On Fri, Jan 22, 2016 at 8:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> Now, when you hear CORS, ...
>
> When I hear "CORS", I think "Will the foreignorigin's service worker be able
> to respond to OPTIONS requests?" because that sounds dangerous. I assume
> preflights will continue to skip both service workers?

Yes. Opting into foreign fetch is the equivalent of OPTIONS.


>> If A wants to fetch something from B without credentials, B's foreign
>> service worker will act as ambient authority since it was fetched with
>> credentials way back when. However, only allowing foreign fetches that
>> include credentials, and making everything else go the network, seems
>> even more dangerous.
>
> What are the threats we're concerned about?

The foreign service worker leaking data about the user. It might have
a CORS policy of Access-Control-Allow-Origin: * meaning it only wants
share responses not tainted by credentials. Due to the foreign service
worker being an ambient authority, that's no longer possible without
careful auditing.


> On the one hand, we have requests which do not include credentials to
> protect the server from accidentally leaking data. I'd suggest that tying
> this entire mechanism to service workers means that we can be a little more
> lax about the kinds of restrictions we impose in response to this threat, as
> essentially all the risk would be opt-in. We couldn't inadvertently expose
> data that the service worker didn't explicitly request, and we could
> mitigate the risk of accidental leakage by requiring some sort of flag on
> the response to return a cached response that was fetched with credentials
> when the request wasn't.

Yes, but none of this quite matches what CORS is able to guarantee and
it is effectively opt-in there too (minus things like the width and
height of an image, which you can get without CORS).


> On the other hand, we have requests which do not include credentials in
> order to protect the user from inadvertent identification. I'm not sure how
> we could effectively mitigate this risk, as the service worker could leak
> data about a user's requests via delayed, credentialed requests, and the
> service worker itself always knows who you are, as it was fetched with
> credentials, and could easily have served up a file hard-coding those
> credentials in some way. Incognito/private mode seems like a better response
> to this kind of use case, but I admit that it's not clear to me how
> widespread this kind of usage might be.

It effectively means that A can no longer use service B while somewhat
protecting the user from being exposed (of course there are other
tricks, but this sure is an effective one).


> We have a carveout in MIX for fetches which a service worker performs in
> response to requests that came from a document. I wonder if we could place
> some restrictions on the kinds of fetches that can be made in response to a
> foreign fetch event. I don't know what those restrictions would look like or
> how they'd work, but, you know.

I don't think that's possible without stack traces or passing tokens
around. Not a big fan of that.


The design we came up with yesterday does not address the ambient
authority issue. We decided it was too hard to solve. So instead the
foreign service worker opts into origins (potentially a wildcard) it
wants to be a foreign service worker for and on top of that we add a
way to make a response "visible" (effectively turn it into a "cors"
response). All responses not made "visible" will become "opaque". When
you make a response visible you also have to indicate what origin you
make it visible for and what response headers you plan on exposing
(aka CORS).


-- 
https://annevankesteren.nl/

Received on Wednesday, 27 January 2016 14:25:33 UTC