New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
6 participants
@igrigorik
Member

igrigorik commented Jul 7, 2015

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

@toddreifsteck

This comment has been minimized.

Show comment
Hide comment
@toddreifsteck

toddreifsteck Jul 8, 2015

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.

Member

toddreifsteck commented Jul 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Jul 14, 2015

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))

Member

igrigorik commented Jul 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@davidben

davidben Jul 14, 2015

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

davidben commented Jul 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@toddreifsteck

toddreifsteck Jul 15, 2015

Member

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

Member

toddreifsteck commented Jul 15, 2015

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

@igrigorik

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Jul 16, 2015

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?

Member

igrigorik commented Jul 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jul 17, 2015

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Jul 17, 2015

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...

Member

igrigorik commented Jul 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@davidben

davidben Jul 17, 2015

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.

davidben commented Jul 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Jul 17, 2015

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.."?

Member

igrigorik commented Jul 17, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jul 18, 2015

Member

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

Member

annevk commented Jul 18, 2015

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

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jul 18, 2015

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@igrigorik
Member

igrigorik commented Jul 20, 2015

@annevk ptal: #30

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jul 20, 2015

Member

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".

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

This comment has been minimized.

Show comment
Hide comment
@igrigorik

igrigorik Jul 20, 2015

Member

Good call, fixed: f7ce98a

Member

igrigorik commented Jul 20, 2015

Good call, fixed: f7ce98a

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

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Oct 10, 2016

Contributor

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

Contributor

yoavweiss commented Oct 10, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment