returns a static HTML page showing a password prompt that you can now safely upload anywhere
Anywhere that you trust, and where the page is hosted securely. For example, a malicious hosting service could alter the password prompt. Or the page as a whole could be put in a frame with a transparent overlay.
Alas, no. ‘frame-ancestors’ does not work in meta. There is no reliable way to prevent click jacking if you are just editing the HTML. That makes sense: in order for these meta directives to even be enacted the HTML will have already begun to download and be parsed.
The old school way is comparing the top level URL with JS and redirecting but there are ways to deal with that
(author here) Yeah, or if it's on http someone could MITM and change the script, or if they are malicious extension on the browser the content can be stolen after decryption.
That felt implicitly obvious to me, but I think you're right and it wouldn't hurt to put those assumptions in the FAQ. Thanks for the feedback!
(If you, or someone else, see other attack vectors, feel free to comment with those)
a supply-chain attack where malicious JS is delivered to the user (even from your own server, as the author of the software, maybe you got hacked yourself for example) is another way
Comments
Anywhere that you trust, and where the page is hosted securely. For example, a malicious hosting service could alter the password prompt. Or the page as a whole could be put in a frame with a transparent overlay.
Clickjacking has been a solved problem for over a decade. Set X-Frame-Options: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-...
Hence the need for a hosting service that you trust. You can't force that header on an untrusted server.
How do I set this in a shared hosting environment like GoDaddy?
You can set a CSP in the HTML head section using a meta http-equiv tag. It has similar functionality to X-frame-options IIRC.
Alas, no. ‘frame-ancestors’ does not work in meta. There is no reliable way to prevent click jacking if you are just editing the HTML. That makes sense: in order for these meta directives to even be enacted the HTML will have already begun to download and be parsed.
The old school way is comparing the top level URL with JS and redirecting but there are ways to deal with that
is it not by default? If no, then i would consider it as a bad design.
or even better CSP options no?
(author here) Yeah, or if it's on http someone could MITM and change the script, or if they are malicious extension on the browser the content can be stolen after decryption.
That felt implicitly obvious to me, but I think you're right and it wouldn't hurt to put those assumptions in the FAQ. Thanks for the feedback!
(If you, or someone else, see other attack vectors, feel free to comment with those)
a supply-chain attack where malicious JS is delivered to the user (even from your own server, as the author of the software, maybe you got hacked yourself for example) is another way
Would it help to employ the ssl cert in the encryption/decryption process and use it as an IV or so?
No. The attacker can mock that just as easily.