wh0 / nix-cache-view

in-browser .nar explorer
https://wh0.github.io/nix-cache-view/
MIT License
13 stars 1 forks source link

Security: extracted files in our origin #1

Closed wh0 closed 2 years ago

wh0 commented 2 years ago

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?

wh0 commented 2 years ago

other idea: somehow generate a blob URL belonging to a different origin. it might suffice to generate from a sandboxed iframe.

wh0 commented 2 years ago

I've just learned that Chrome doesn't even bother to sniff the blob's type 💀

wh0 commented 2 years ago

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