ipfs-companion icon indicating copy to clipboard operation
ipfs-companion copied to clipboard

Content Security Policy Error when loading scripts hosted on IPFS

Open karmanyaahm opened this issue 3 years ago • 1 comments

Describe the bug When a website includes a script that's hosted on an DNSLink domain, and has a restrictive Content Security Policy, the scripts fail to load, and the website doesn't function properly.

To Reproduce Steps to reproduce the behavior:

  1. Make sure IPFS Companion is enabled
  2. Go to https://cactus.chat/demo/
  3. See that the comments section, hosted at https://latest.cactus.chat/cactus.js doesn't load, because latest.cactus.chat is served over DNSLink. (CSP errors in the console)
  4. Disable IPFS Companion.
  5. Everything works well.

Expected behavior Go to the website and all the assets load. There is no CSP error in the console.

Desktop (please complete the following information):

  • OS: Arch Linux
  • Browser: Firefox
  • Version: 90.0b5 Chromium 91.0.4472.77 also has the same behavior.

Possible Solution Modify CSP to gateway. I used the Mozilla Laboratory extension to modify the CSP on the website. My IPFS Gateway is at http://127.0.0.1:8080, so I added http://127.0.0.1:8080/ipns/*.cactus.chat to the script and style CSP directives (in a real solution font-src etc. should also be added). only /ipns/*.cactus.chat here because that's what the script-src and style-src already specified. IPFS Companion should do this automatically.

Another solution would be to stop intercepting URLs when scripts and stylesheets are being loaded over IPFS.

Note - I'm not associated with cactus.chat I just noticed this problem with companion, so I'm making this bug report. Note 2 - related issues - #701 seems like the solution 2 that I said, but it seems to be closed and that behavior still doesn't happen? #624 's solution is to disable window.ipfs, but the toggle for that is locked and there seems to have been no progress on that?

karmanyaahm avatar Jun 12 '21 23:06 karmanyaahm

Thank you for reporting this @karmanyaahm

Quick thoughts:

  • Ideally, we would modify CSP to match redirect, making entire thing self-contained. Our browser extension is able to modify HTTP headers, but we need to check if that happens before CSP policy is executed by the browser context (and if the order is the same in Chromium and Firefox).

  • If that is not possible, alternative is to disable redirect-by-default when CSP header is detected, to avoid breaking pages by default, and requiring manual opt-in from the user.

  • #701 is just the manual toggle that enables users to fix broken websites and #624 is no longer relevant as window.ipfs got deprecated (https://github.com/ipfs/in-web-browsers/issues/172)

Update: this is limited to Firefox.

lidel avatar Jun 17 '21 19:06 lidel