CSP: Consider allowing `frame-ancestors` to work for subresource loads.

[mikewest]

From @mikewest on August 22, 2015 0:1

After a quick chat with @briansmith, I think I'm convinced that it would be worth giving subresource fetches the capability of canceling themselves based on the resources that requested them. That is, frame-ancestors (or embedder-src, or however we'd like to spell it) would work on <img> in the same way it works on <iframe>. This could shut down a class of information leakage attacks (e.g. Facebook might want to say that an image on their CDN can only be loaded in the context of facebook.com, but not in awesome-facebook-images.info), could make it moderately more difficult to detect whether a user is logged in (as logged-in-logo.png won't load on evil.com for anyone, logged-in or not), and could help defend against hotlinking.

Worth considering.

Copied from original issue: w3c/webappsec#458

[mikewest]

From @annevk on August 22, 2015 7:30

How does this make sense for CSP though? This seems a lot like http://www.w3.org/TR/from-origin/.

[mikewest]

From @briansmith on August 22, 2015 16:2

How does it not make sense for CSP, given that CSP already does it for iframes? It wouldn't make sense to do it separately now.

I agree that this looks a lot like from-origin, and part of the motivation looks similar to what you described in [1]. Referrer policy makes this more of an acute issue, because Referer header checks will work less and less well.

[1] https://annevankesteren.nl/2011/02/from-origin

[mikewest]

From @annevk on August 24, 2015 11:53

Well an <iframe> establishes a browsing context which makes it eligible for a CSP policy. A subresource doesn't have a policy of its own.

[mikewest]

From @hillbrad on August 24, 2015 16:23

I'll give the same caution here that I did for from-origin, which is that I
think it comes close to violating the HTML priority of constituencies, and
that it is especially dangerous to make security features which are
intended to protect the user work against them. If we make CSP the
enforcement mechanism of choice for DRM-ish things like "anti-leeching", it
gives users an incentive to disable them. There are already extensions
that e.g. disable X-Frame-Options; I worry that use of such would become
more widespread if CSP is seen as something that breaks the web - to no
security benefit for the user - by blocking third-party font and image
loads.

I don't think "defending against hotlinking" is a valid goal for CSP. (if
it is a valid goal for web technology at all)

[briansmith]

give the same caution here that I did for from-origin, which is that I
think it comes close to violating the HTML priority of constituencies,

This isn't a priority of constituencies issues. Users create content as well as consume content.

I worry that use of such would become
more widespread if CSP is seen as something that breaks the web - to no
security benefit for the user - by blocking third-party font and image
loads.

If users have to pay for hosting their content, then anti-leaching absolutely does help them.

But, is this really just about anti-leaching? Doesn't this have positive benefits as far as CSRF is concerned? I can't remember, but I think that CSRF issues are the reason that Mike and I were discussing this in the first place--probably after me mentioning how terrible EPR is.

[briansmith]

Oh, yes, this is also an enabler/accelerant for improved Referer policy, including no-Referer-by-default, because it covers one of the non-privacy-invasive use cases of the Referer header. Also, insofar as priority of constituencies is concerned, frame-ancestors already has the same issue with iframes.

[mikewest]

Does anyone feel strongly enough about this to make a more concrete proposal?