Document needed changes in Content-Security-Policy / possibly update script for better CSP support

[tbroyer]

I've setup a CSP on my blog, which by default blocks the script.

Changes I had to make to make it work:

• add https://widget.battleforthenet.com to script-src
• add https://widget.battleforthenet.com to child-src
• add 'sha256-2V9nAQ7jmNi+KiCY0h7ybeJqEOY6KbSS7uPieMa6VVc=' (or unsafe-inline) to style-src;
  however that means that if you change the content of the stylesheet, it'll be blocked; and unsafe-inline grants too much rights for other stylesheets.
  How about using an external stylesheet instead (like Twitter does) so the style-src can simply whitelist https://widget.battleforthenet.com and you're free to make last-minute changes to the stylesheet?

Did I miss something?

(note that I've only checked that this displays the popup and it can be dismissed, not that the form can be submitted)

[mikemorris]

An external stylesheet as in hosting at a separate (cookie-less?) domain for static assets, or a different subdomain? Good idea for future iterations here, but not gonna happen today 😄

[tbroyer]

Yeah sure, of course I was late; and indeed this also serves as a suggestion for next time (we all hope it won't be needed, yet we all know it will…).

To answer your question: hosting the CSS at the same origin as the script and iframe would be (have been) OK; no need for a different subdomain. The changes required on a CSP would be “whitelist https://widget.battleforthenet.com on script-src, style-src, and child-src” (maybe a bit more to ensure the form works too)

I suppose @mikewest or @ScottHelme could help find the best settings 😉

[emma-sg]

In the future, hashes could be calculated and automatically added with the build process.

[AfroThundr3007730]

Ok, so after adding https://widget.battleforthenet.com to script-src and child-src in my CSP, I was still getting the following in the console:

17:34:31.487 Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src https://www.example.com https://cdn.example.com https://widget.battleforthenet.com”). Source: #_bftn_wrapper { position: fixed; left: ....

So the style for the iframe was still being blocked, most likely because I don't allow unsafe-inline in the policy. I got around this by adding the relevant code to my css directly:

#_bftn_wrapper {
	position: fixed;
	left: 0px;
	top: 0px;
	width: 100%;
	height: 100%;
	z-index: 20000;
	-webkit-overflow-scrolling: touch;
	overflow-y: auto;
}

#_bftn_iframe {
	width: 100%;
	height: 100%;
}

Note: Adding 'sha256-2V9nAQ7jmNi+KiCY0h7ybeJqEOY6KbSS7uPieMa6VVc=' to script-src fixes the issue for Chrome, but not Firefox. The above CSS allows the widget to function correctly despite the CSP error in the console.

[rubbingalcoholic]

Thanks for reporting. I’ll add a note about CSP security to the documentation tonight. In general, I’d advise against using the sha256 hash of the widget code as we do push out changes often enough for the hash to break. For a high-security application, I recommend self-hosting the widget (including its popup iframe) instead of using the Github version. To build it for local deployment, use the instructions in DEVELOPING.md and build the widget once `npm run build` - then copy the contents of the dist folder to wherever you want to host it. Finally, there’s a secret option to point the iframe at an alternative location (see the top of https://github.com/fightforthefuture/battleforthenet-widget/blob/master/src/widget.js - if you pass in `_bftn_options.iframe_base_path = 'https://example.com/bftn-widget/iframe/iframe.html'` (your URL) before loading the widget, it will be fully hosted on your server. Let me know if I can assist further. From: Eddie James Carswell II Sent: Tuesday, December 12, 2017 5:04 PM To: fightforthefuture/battleforthenet-widget Cc: Subscribed Subject: Re: [fightforthefuture/battleforthenet-widget] Document neededchanges in Content-Security-Policy / possibly update script for better CSPsupport (#106) Ok, so after adding https://widget.battleforthenet.com to script-src and child-src in my CSP, I was still getting the following in the console: 17:34:31.487 Content Security Policy: The page’s settings blocked the loading of a resource at self (“default-src https://www.example.com https://cdn.example.com https://widget.battleforthenet.com”). Source: #_bftn_wrapper { position: fixed; left: .... So the style for the iframe was still being blocked, most likely because I don't allow unsafe-inline in the policy. I got around this by adding the relevant code to my css directly: #_bftn_wrapper { position: fixed; left: 0px; top: 0px; width: 100%; height: 100%; z-index: 20000; -webkit-overflow-scrolling: touch; overflow-y: auto; } #_bftn_iframe { width: 100%; height: 100%; } Note: Adding 'sha256-2V9nAQ7jmNi+KiCY0h7ybeJqEOY6KbSS7uPieMa6VVc=' to script-src fixes the issue for Chrome, but not Firefox. The above CSS allows the widget to function correctly despite the CSP error in the console. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.