Comments (19)
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?
from fileapi.
CC: @annevk
from fileapi.
I think crossOrigin
is confusing given the feature in HTML with the same name that kinda means the opposite of this. Cross-origin blob:
URL also seems confusing and doesn't really work well if we ever allow navigating to or downloading Blob
objects directly.
This is probably the correct design, but it does make me a bit uneasy that we copy the policy container when doing URL.createObjectURL()
. Now if origin becomes part of the policy container how would we reconcile this?
cc @antosart
from fileapi.
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...?
from fileapi.
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.
from fileapi.
Yes. I think this makes things possible that were not possible before. For example, a page with default-src blob:
should not be able to exfiltrate any information at the moment. After this proposal, it will be able via a cross-origin blob.
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 blob:
in CSP does not allow cross-origin blobs, and instead a new keyword is needed for allowing framing them.
from fileapi.
I think
crossOrigin
is confusing given the feature in HTML with the same name that kinda means the opposite of this.
How about changing the name to crossSite
?
Cross-origin
blob:
URL also seems confusing and doesn't really work well if we ever allow navigating to or downloadingBlob
objects directly.
What does navigation to Blob
objects look like?
Can this be solved if we expose this option to URL.createObjectURL()
instead of Blob
objects?
I.e.: URL.createObjectURL(blob, {crossOrigin: true})
Yes. I think this makes things possible that were not possible before. For example, a page with default-src blob: should not be able to exfiltrate any information at the moment. After this proposal, it will be able via a cross-origin blob.
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:
- To create a Blob, you need a script execution first. If that's an unintended script execution, then that's game over.
- The content of Blob can be untrustworthy, but in this case the person creating the Blob URL can apply CSP and/or sandbox with attributes or meta tag to restrict them.
I think that sites which are using tight CSP like default-src blob:
are pretty rare, and if they want, they should have a way to restrict them. But that should not warrant inavailability for this API for others by default (which are the majority).
from fileapi.
I'm not sure how using "site" is better? It has a defined meaning in HTML and it's not related to opaque origins.
What does navigation to Blob objects look like?
Imagine the navigation API gaining support for Blob objects.
I don't think it would be better if we did this through URL.createObjectURL()
as that wouldn't help migration away from that API.
Exfiltration through top-level navigation is "fine" as that's "visible".
from fileapi.
I'm not sure how using "site" is better? It has a defined meaning in HTML and it's not related to opaque origins.
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.
What does navigation to Blob objects look like?
Imagine the navigation API gaining support for Blob objects.
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. navigation.navigate
), and we can decide to either block it, or convert the given blob into URL.
From this API point of view, we just need 2 things.
- When a unique Blob or Blob URL is rendered as a document, it is treated cross-site to the creator.
- When a unique Blob or Blob URL is used as a resource, it is origin tainted.
If we can acheve this with Blob objects (which I believe we can), then it's probably non-issue for navigating/downloading Blob objects.
Exfiltration through top-level navigation is "fine" as that's "visible".
I think we are in agreement that it's not a perfect protection then 🙂 And an attacker can call history.back()
to hide it, so I doubt how "visible" it would be.
from fileapi.
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.
from fileapi.
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:
- Support a new
allow-unique-origin
sandbox flag that can be used with both CSP sandbox andiframe#sandbox
- Add support for attaching response headers to created Blobs
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
from fileapi.
That still doesn't address the authority conflict: #192 (comment). I don't think we can ignore that.
Other feedback:
- This seems like it should be its own proposal to give it proper visibility, given how much complexity it adds to the web platform security story. "Unique origin" is also easily confused with "opaque origin".
Blob
with headers seems interesting. It would also allow for some download use cases people had as well. Processing model needs a lot more detail though.
from fileapi.
That still doesn't address the authority conflict: #192 (comment). I don't think we can ignore that.
What do you consider "circumvent sandboxing"?
If that means CSP restrictions, is opt-in like frame-src blob: 'allow-unique-blob'
enough to satisfy your concern?
from fileapi.
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.
from fileapi.
Got it. Given @annevk and @antosart both believe that opt-in is necessary, I've added an opt-in requirement for sites which enforces frame-src
(and default-src
).
I guess there were other naming concern about crossOrigin. Maybe crossSite: true
or unique: true
might be better?
from fileapi.
Could you and @ddworken first work out what proposal you actually want to pursue?
from fileapi.
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 fileapi.
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 blob:
URLs this should probably go elsewhere. Probably whatwg/html.
from fileapi.
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
blob:
URLs this should probably go elsewhere. Probably whatwg/html.
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).
from fileapi.
Related Issues (20)
- TPAC planning and specification status report HOT 2
- Async factory methods for Blob and File HOT 4
- Support using AbortController with FileAPI HOT 6
- Specify how filenames from the OS map to File's `name` property HOT 2
- features request:add SynFileReader for Avoid Callback Hell Programming from FileReader HOT 1
- Clarify UUID version HOT 1
- Align with ReadableStream changes HOT 1
- Issues with MIME types HOT 2
- Consider allowing re-reads after snapshot state change for applications loaded from file: URIs
- Disparity in `loadend` event dispatch between spec, implementation & tests HOT 4
- blob: slice() without valid content type yields unexpected results HOT 2
- TPAC 2022 status report HOT 1
- Consider adding `blob.dataUrl()` method, or some other analogue to `readAsDataURL` HOT 9
- Broken references in File API
- Byte stream support for `stream()`?
- Function signature change: reading all bytes from a stream
- createObjectURL with ReadableStream HOT 2
- Don't export "resolve" HOT 4
- Specify actual byte reading algorithm for Blob.stream()
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fileapi.