search

privacycg / storage-access-headers

Proposal for HTTP headers related to the Storage Access API
https://cfredric.github.io/storage-access-headers/
Creative Commons Attribution 4.0 International
26 stars 2 forks source link

Consider restricting leakier no-cors requests to not use these headers #8

Closed bvandersloot-mozilla closed 2 months ago

bvandersloot-mozilla commented 7 months ago

If Firefox or Safari were to adopt these headers for top-level cross-site fetches that are no-cors (e.g. a regular <img>) it would make it possible to leak information that I think is not currently leak-able.

I am not certain what the right decision is here, but given that Safari and Firefox do not have positions or implementations on requestStorageAccessFor, this is an expansion in where storage access can be used, not just an ergonomic improvement.

The most direct translation of this proposal to strictly ergonomic improvement would be to restrict the Sec-Fetch-Storage-Access headers to [i]frame fetches only.

arturjanc commented 7 months ago

it would make it possible to leak information that I think is not currently leak-able

Given that the ability to load subresources (i.e. not just iframes, but images, scripts, etc.) seems like a significant part of this proposal, it would be good to understand the leak concerns better to see if we can instead address these.

Do you mean that if we were to add the Origin header to no-cors requests eligible for retrying a load with credentials then we would disclose the origin of the requesting document to servers hosting the resource? (This assumes that the requesting page or the user intentionally removes the Referer header via Referrer Policy or similar.)

bvandersloot-mozilla commented 7 months ago

No, I'm still thinking about a leak akin to the typical no-cors leakiness. Although I suppose the case I am thinking of only applies if the embeddee is not careful about sending these headers only in framed contexts.

Consider: a third party has storage access for an embed. Then they send the header for all of its images in the frame, some of which have varying size based upon profile details. If the embedder wants to read those profile details they can load those images in the top level. (I see now that this only works if the embeddee does not validate that the image is going into the iframe.

arturjanc commented 7 months ago

I think this ties in quite nicely with https://github.com/cfredric/storage-access-headers/issues/7 - i.e. I agree that this is a concern, but IMHO the origin allowlisting mechanism discussed in that issue might be a reasonable solution. (It can still be a footgun if developers use the * wildcard to allow credentialed requests from anywhere, but depending on how we name the value it should at least nudge developers to think about a tighter allowlist).

cfredric commented 2 months ago

Sorry for the late response here - I believe I see the attack/leak you're describing @bvandersloot-mozilla, and I agree with @arturjanc that the allowed-origin=... addition should give the third-party the ability to ensure that they're protected (provided they don't use the wildcard as a "please just work" option). I'll close this since I merged #14, but please reopen if you think there's more to discuss here.