-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Define behavior of preload when CSP was changed between fetching and consuming #7686
Comments
I've added a test for this: web-platform-tests/wpt#33109 In Firefox the behavior is to not block the image, and in Chromium/Safari it is. What should be the right behavior? I personally am forming an opinion that dynamically added CSP is a problematic feature - can create a false sense of security, and then fail to protect in certain edge scenarios. |
My understanding is that the https://w3c.github.io/webappsec-csp/#meta-element does call out |
It's spec'ed as a second fetch that doesn't go through all the checks (consume is called before I'm a bit concerned about memory cache and implementations though - they are not clearly defined and don't always go via fetch. There could be a scenario where:
|
It's been a while since I looked at any of this, but I think (thought?) that https://html.spec.whatwg.org/multipage/images.html#update-the-image-data was the path through which we'd end up going for More practically, though: I don't think there would be security harm to adopting Firefox's behavior. The request already happened, so exfiltration risks can no longer be mitigated. There's some conceptual weirdness about being able to display an image you can't request, but it's not security-relevant weirdness. Assuming that "consume" is in fact used somewhere, I could imagine us resolving this one of two ways:
The former seems like more work in the spec, the latter is more work in implementations. 🤷 One other question, though: how does this work with redirects? Would blocking the original URL but allowing the redirect target to load be possible via the "consume" algorithm, thereby potentially revealing redirect endpoints? |
Of course, but I meant the case where something is already in the list of available images. And there is no mentioned of when an image is removed from that list.
It is called from the fetch algo at section 10.
Right. I think it's more about an expectation around what happens when you add a CSP dynamically. I think it is a security-relevant weirdness if someone added a CSP at some phase in the lifetime of a document to completely disallow remote scripts, and then a remote script is able to execute because it happens to have remained in the cache (preload cache, memory cache, or anything else above fetch).
I don't think the spec work is big, I can take it on if Firefox wants to go down this route. My issue is that it doesn't end at preload - preload is a symptom for "memory cache", they usually share an implementation, which is unspecified and can result in scenarios where things are arbitrarily allowed or denied based on the capacity of the cache.
The redirects are "resolved" during the preload. I was thinking we need to call block request on the pre-consume request and block response on the response received from preload. If any intermediate redirect had happened already it shouldn't be blocked. For now I posted an editorial note PR that describes the status quo. |
Got it, thanks for the pointer!
Yes, I agree. Now that I understand that the preloaded resource consumption mechanism bypasses CSP for things other than images, I'm more interested in Firefox changing its behavior to match Chromium/Safari. My mental model has been that CSP aims to gate access to resource execution on the one hand, and exfiltration on the other (though I'm certainly guilty of caring much more about the former than the latter). We defined it in terms of Fetch as that seemed like the most straightforward way to represent both gatekeeping mechanisms. It would be ideal for us to define access to various caches in ways that respect the rules that developers aim to apply via CSP. I think the approach you suggest for the pre- and post-consume algorithms makes sense, though I'd note that it might also need to address resource upgrading/mixed content checks, which are a little complicated as they happen inbetween CSP reporting and CSP enforcement in order to give developers the ability to find them on their pages. |
OK, so this is to deal with a scenario where mixed content is allowed at first, but later a CSP |
The mixed content bits shouldn't change during the lifetime of a page (though I think they technically can in Chrome, it's an edge case well-worth ignoring, as it would involve either enterprise policy or the user poking at settings pages; either way, forcing a reload is probably fine). The upgrade bits would, I think, cause mismatches between the requested resource and the cache. Consider |
OK,
OK, if it can't change during the lifetime of the document then it doesn't apply here - the URLs would either be the same or |
The URLs wouldn't be the same: assuming the preloaded resource triggered by I guess there wouldn't be web-visible impact to that, insofar as we'd simply proceed with Fetch and pull the resource out of the disk cache after upgrading its URL? |
Yes, exactly. |
FWIW, I agree with Mike that CSP (and other policies) should be enforced when "consuming". Thanks for catching this! |
OK, so I guess I can merge the WPT and post a PR; Or do we need anyone else from Mozilla to be on board? |
I'll double check, but I suspect those responsible for CSP will agree. |
Reopening, should not have been auto-closed until whatwg/fetch#1411 is merged |
Also correct spelling of a variable. Tests: web-platform-tests/wpt#33109 & web-platform-tests/wpt#33205. Closes whatwg/html#7686.
Consider the following scenario:
<link rel=preload as=image href="https://some-domain.com/image.png">
The document starts loading the image
Then a scripts adds CSP, before the image is discovered:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
(or anything that doesn't allow the image)And then an image
<img src="https://some-domain.com/image.png" />
Should the response that has already been loaded be consumed by the
img
element, or should CSP be applied again, denying the response from being used by the image element?The current specs & WPT don't exactly cover this case. The way the spec is written, there is no additional CSP check upon consumption.
The text was updated successfully, but these errors were encountered: