Same-origin policy & observing no-cors fetches #27

Closed
igrigorik opened this Issue Jul 7, 2015 · 16 comments

Projects

None yet

6 participants

@igrigorik
Member

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)

@igrigorik igrigorik changed the title from Same-origin policy & observing fetches to Same-origin policy & observing no-cors fetches Jul 7, 2015
@igrigorik igrigorik referenced this issue in w3c/ServiceWorker Jul 7, 2015
Open

"no-cors" CSS SOP violation #719

@toddreifsteck
Member

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
Member

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
Member

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

@igrigorik
Member

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
Member
annevk commented Jul 17, 2015

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
Member

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
Member

@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
Member
annevk commented Jul 18, 2015

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

@annevk
Member
annevk commented Jul 18, 2015

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
Member

@annevk ptal: #30

@annevk
Member
annevk commented Jul 20, 2015

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
Member

Good call, fixed: f7ce98a

@plehegar plehegar closed this in #30 Jul 21, 2015
@yoavweiss
Contributor

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

@plehegar plehegar added the security label Oct 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment