Closed wh0 closed 2 years ago
other idea: somehow generate a blob URL belonging to a different origin. it might suffice to generate from a sandboxed iframe.
I've just learned that Chrome doesn't even bother to sniff the blob's type 💀
let's lock things down to application/octet-stream, and later we can separately add previewing functionality if we come up with a neat way to do it
We create
blob:
URLs to refer to the files we extract. Currently these blobs don't have a content type set, so the browser infers. And that allows them to render HTML files, which I assume allows them to run arbitrary JavaScript as well. See here:https://github.com/wh0/nix-cache-view/blob/1a5bba2d55272506ff2f7c6af27cf0bf92d79474/nar.html#L30
It would be better not to let users run arbitrary scripts this way though. I want to be able to serve this from an origin shared with other things (I'll just say it, on my GitHub pages subdomain), and I don't want extracted things to have access to that whole origin.
If it were up to me, I would just set an
application/octet-stream
content type on the blob. It would at least be safe that way. But then we would lose the convenience of viewing certain unthreatening file types without a download, e.g. plain text and media files (although this seems uncommon for our use case). Or to view the source of HTML files. Maybe we could add some UI to let the user choose what format to preview a file as? With some heuristic based on the file extension?Or is there another way to let the browser infer the file type and preview it while not allowing scripting, network access, etc? Content-Security-Policy would work, if we were serving these extracted files from a server. Is there an equivalent for blob URLs?