-
Notifications
You must be signed in to change notification settings - Fork 44
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
Proposal: Add a capability to create a Blob URL with a unique (non-opaque) origin #192
Comments
CC: @annevk |
I think This is probably the correct design, but it does make me a bit uneasy that we copy the policy container when doing cc @antosart |
I just skimmed trough this, but this mentions that the blob would NOT inherit CSP from the creator, hence I believe it would not inherit any policies, hence we would not copy the policy container in this case...? |
You're right, but that makes me wonder if this could be used to circumvent sandboxing. While an opaque origin has some unique restrictions, policies can go further. |
Yes. I think this makes things possible that were not possible before. For example, a page with I am reading https://github.com/shhnjk/Safe-Blob-URL#is-there-a-way-to-block-cross-origin-blob-urls-in-iframe and I think it would be better if |
How about changing the name to
What does navigation to
I think you can already exfiltrate information today (PoC), because there is no restriction of navigations. To me, opt-out (i.e. use keyword if you want to block unique Blob URL) makes sense because:
I think that sites which are using tight CSP like |
I'm not sure how using "site" is better? It has a defined meaning in HTML and it's not related to opaque origins.
Imagine the navigation API gaining support for Blob objects. I don't think it would be better if we did this through Exfiltration through top-level navigation is "fine" as that's "visible". |
Note that this proposal creates new "site", which is not an opaque origin. And because it is designed to always be cross-site when rendered as a document, the site definition in HTML clearly matches this API.
I think that's not an issue. Navigation API only supports same-origin endpoints for most of API (like navigate event). There are probably few places where cross-origin Blob "could be" supported (e.g. From this API point of view, we just need 2 things.
If we can acheve this with Blob objects (which I believe we can), then it's probably non-issue for navigating/downloading Blob objects.
I think we are in agreement that it's not a perfect protection then 🙂 And an attacker can call |
If you're looking to block exfiltration via navigation, there's already the Navigation API for that. You could use an allowlist of navigation hosts or simply block all blob URLs. |
Hi all! I work with @shhnjk at Google, and have been thinking about an alternate API shape that is more broadly applicable while still solving many of the same goals. At a high level, my proposal is to:
You can see the full details in Sandbox allow-unique-origin and customizing Blob response headers. I'm curious to hear folks thoughts on this alternative shape which enables creation of unique origins for iframes and HTML responses. cc: @mikewest @arturjanc |
That still doesn't address the authority conflict: #192 (comment). I don't think we can ignore that. Other feedback:
|
What do you consider "circumvent sandboxing"? |
I haven't done a thorough analysis as to whether that is the sole issue, but if it is, I think that would address my concern, yes. |
Got it. Given @annevk and @antosart both believe that opt-in is necessary, I've added an opt-in requirement for sites which enforces I guess there were other naming concern about crossOrigin. Maybe |
Could you and @ddworken first work out what proposal you actually want to pursue? |
Within Google, we are inclining towards allow-unique-origin option (especially because it also solves an additional problem). But we'd love to hear opinions from Mozilla folks as well. CC: @mozfreddyb, @dveditz. |
From talking to a few Mozilla folks, they have good impression on the problems these proposals are aiming to solve, but it's too early to call for a position. Part of the reason is that there are 2 proposals which aren't specced (i.e. needs more details). I think we should tackle allow-unique-origin option (reasoning), and brush out details (e.g. either to have a list of allowed headers). @annevk, WDYT? |
I don't think I have anything to add beyond my earlier comments at this stage. One of which was that if this goes beyond |
Thanks! I've opened whatwg/html#9623, to track this in whatwg/html. One we settle on discussion there, I will open an issue in File API to propose adding headers to Blob object (or I can do it now if that's prefered). |
Up-to-date details and FAQ for this proposal is available at https://github.com/shhnjk/Safe-Blob-URL
Proposal
Expose a
crossOrigin
option to BlobPropertyBag in the Blob constructor and a read-onlycrossOrigin
property in Blob instances.A cross-origin Blob URL is special in a few ways.
blob:scheme://[UUID]/UUID
.https://[b9b68b26-a98b-4ad6-b089-33d2afa96944]
).Why do we need this?
It aims to solve 2 problems.
XSS through Blob URLs
Blob URL is useful for loading locally available resources. However it also leads to XSS bugs.
The cross-origin Blob URL is designed in a way that these XSS won't happen (because a script will execute in a unique origin).
A native alternative to sandbox domains
Many Web apps require a place to host user contents (e.g.
usercontent.goog
,dropboxusercontent.com
, etc) to safely render them. In order to do so securely (e.g. to avoid exploitable XSS, cookie bomb, and Spectre attacks), a site needs to register a sandbox domain, add it to the public suffix list, and then host user contents in randomly generated subdomains. However this is not something that any site can afford due to engineering and maintenance cost.The cross-origin Blob URL provides a way to render user contents in a cross-site context without such setup.
The text was updated successfully, but these errors were encountered: