Same-origin policy & observing no-cors fetches

[igrigorik]

An attacker attacker.example can figure out what resources a stylesheet target.example loads by including it on attacker.example and using either the resource timing (shipped) or service worker (about to ship) API. This violates SOP. (@annevk)

• "no-cors" CSS SOP violation ServiceWorker#719
• https://bugzilla.mozilla.org/show_bug.cgi?id=1180145

[toddreifsteck]

Has a test case to validate this hole in Chrome/Firefox been created? I'd like to re-use it to validate Microsoft browsers.

[igrigorik]

@toddreifsteck see: http://krijnhoetmer.nl/irc-logs/whatwg/20150703#l-313

[igrigorik]

Oh, and I believe this is the corresponding WebKit bug, since I don't see it linked in the paper:
https://bugs.webkit.org/show_bug.cgi?id=29820 (@davidben, w3c/ServiceWorker#719 (comment))

[davidben]

Er, to clarify, that's not the corresponding WebKit bug for this stuff. It's the corresponding WebKit bug to this paper, https://www.linshunghuang.com/papers/css.pdf, which is an example of cross-origin CSS info leakage being a concrete problem in the past.

ETA: Full context for my quoted comment:

Oh yuck. Yeah, I think I agree with Anne that we should remove these requests from SW and Resource Timing unless you add the crossorigin attribute. These kinds of "the contents are secret, but if they happen to parse as foo, you can execute it" security policies are super-hairy. We shouldn't add new ones.

In fact, cross-origin CSS has already bitten us in the past because the CSS parser is extremely error-tolerant. See https://www.linshunghuang.com/papers/css.pdf

[toddreifsteck]

Microsoft agrees this should be explicitly called out in the spec and blocked.

[igrigorik]

Looking at the plumbing, I think step 3 in processing is where we need to restrict this behavior:

For each resource fetched by the current browsing context, perform the following steps...

That said, I'm not sure about the correct language to carve out ~"fetches initiated by Documents fetched with no-cors flag". @annevk any suggestions on this one?

[annevk]

The way this should really work is through the fetch registry I think. Resource timing would hook into that. Then we need CSS to be defined in terms of Fetch and set some kind of "opaque request flag" for no-CORS CSS subresources. And the fetch registry has a view that doesn't expose opaque requests which all APIs would be required to use.

Until that time, calling out no-CORS CSS somehow and saying we're waiting for everything to be written in terms of Fetch seems like the best monkey patch you can do, but I'm open to suggestions.

[igrigorik]

Ok, for time being, how about..

For each resource fetched by the current browsing context, excluding resources fetched by cross-origin CSS documents fetched with no-cors policy, perform the following steps...

[davidben]

Nit: Unless we've already lost that game (but skimming around, it doesn't seem to be the case), we shouldn't call anything a "CSS document". A document is a very particular kind of object with a whole lot of semantics attached to it. CSS does not create those things.

[igrigorik]

@davidben I'm not clear on what you mean with "CSS does not create those things".. Are you suggesting I strike the "document" part and simply refer to it as "fetched by cross-origin CSS resources fetched with.."?

[annevk]

Yes, use "cross-origin CSS resource" or "cross-origin stylesheets".

[annevk]

I would also appreciate a note about refactoring that in terms of Fetch down the line, so that those implementing might do the right thing.

[igrigorik]

@annevk ptal: #30

[annevk]

Yeah looks good. Though you might want to point to https://fetch.spec.whatwg.org/#concept-fetch instead of HTML, since the HTML definition doesn't handle a number of things, and doesn't call it "no-cors".

[igrigorik]

Good call, fixed: f7ce98a

[yoavweiss]

Was a test for this ever added to web-platform-tests?

[hiroshige-g]

WPT

https://wpt.fyi/results/resource-timing/no-entries-for-cross-origin-css-fetched.sub.html

according to https://chromium-review.googlesource.com/c/chromium/src/+/3781346 and the CL will fix the behavior on Chrome.