Address high-priority content security policy concerns

[tjcouch-sil]

As a user of an extension, I would like to connect to the internet so that I can get content.

Crowd.Bible's people tried to make a paranext extension, and it required security access beyond our current CSP's abilities. They modified the CSP's to fit their needs as described here: https://github.com/etenlab/docs/blob/dev/docs/DevTeam/paranext-extension.md#known-problems-and-ways-to-tackle-them

We need to evaluate modifying our content security policy in renderer's index.ejs and in webview's web-view.service.ts to meet the needs of extension developers in a secure way:

• Evaluate data: uris for supplying images and such. Are these secure?
  • Note: the little resize triangle on floating windows use rc-dock's built-in class .dock-panel-drag-size-b-r, which has a data url on background-image.
  • Google's CSP evaluator allows this. I can't find much that says anything bad about it regarding specifically images and such. Bad on script-src though
  • Seems like this is probably ok for media:
    • data URI scheme - Wikipedia
    • Data URLs - HTTP | MDN
    • Is it safe to allow data URI's for img's? And best way to do it? · Issue #187 · mganss/HtmlSanitizer
    • xss - Content Security Policy https: and data: meaning - Information Security Stack Exchange
    • xss - Is including the data scheme in your Content Security Policy safe? - Information Security Stack Exchange
    • Content Security Policy Level 3
  • If we end up allowing data uris, change the comment in webpack.config.ts
• Determine if we should add https: to media sources and/or connect-src
  • Yes. Done. We will use Create Electron protocol handler to block internet access when offline #473 to prevent offline internet access
• Determine if we should add to script-src a way to run wasm like wasm-unsafe-eval or papi-extension: - some thoughts https://github.com/WebAssembly/content-security-policy/blob/main/proposals/CSP.md
  • Since wasm code does not allow anything more than the code can do already, let's allow it. However, we should only allow it in the child iframes since this may be a possible avenue for webviews to inject code into the parent. Needs investigation
  • It seems wasm code may not be able to access anything other than what the JavaScript gives it
    • Probably would be good to check running wasm especially in extension main file to make sure fetching goes through our function
    • Discussion with Marc Durdin and Andrew Bulin on Slack confirming IO is through the JS environment
    • https://github.com/WebAssembly/content-security-policy/blob/main/proposals/CSP.md#webassembly-sandbox
  • Looks like emscripten, a C++ wasm compiler, may use XmlHttpRequest behind the scenes
    • We can't restrict CSP on extension host right now. We could do one of a few things:
      1. Say no XmlHttpRequest on extension host. Deal with it. There already isn't XmlHttpRequest in node, so this is default and current behavior
      2. Change extension host process into a hidden Electron BrowserWindow so we can enforce our CSP
      3. Implement our own XHR
  • Maybe we can just tell people to include wasm in their extension and allow papi-extension:? That would mean any extension can load any script. Is this ok?
  • Should we shim out web assembly from node?
  • Should we require some kind of integrity check for wasm modules? How? What about vulnerability scanning?
• Determine if we should not delete XmlHttpRequest on webviews
  • Let's try to make a monkey-patch Create WebSocket and XmlHttpRequest access on PAPI - frontend #74
  • Glenn wants no way to access internet without going through our stuff. window.top is readonly - prevents us from isolating webviews #176 option 1 basically means that will not be possible, but at least anything would still have to go through our CSP
• Determine if we want to allow style-src 'unsafe-inline'
  • Let's allow it. A lot of devs consider it unwieldy not to have this. MUI loads styles in like this. Lots of other libraries do as well.
  • Some risks detailed
    • https://stackoverflow.com/questions/30653698/csp-style-src-unsafe-inline-is-it-worth-it
    • https://scotthelme.co.uk/can-you-get-pwned-with-css/
    • Note that Google's CSP checker does not warn or error on this
• Determine if we should sync the CSP between index.ejs and web-view.service.ts
  • No. There are a few things that must be more restrictive in webview iframes. However, most of it should be the same.
• Determine if we should add other elements to the list of disallowed elements other than script like a and link
  • Yes. There are a number of quite insecure tags
• Should we allow webviews to be iframes to other urls?
  • Looks like it's not a big security concern if it's on a different origin. Removing allow-same-origin prevents us from getting in trouble with blob:s which do execute on same origin
  • javascript - Is it safe to have sandbox="allow-scripts allow-popups allow-same-origin" on <iframe />? - Stack Overflow
  • Security Issues for allowing users to add own JavaScript to your site? - Stack Overflow
  • Play safely in sandboxed IFrames  |  Articles  |  web.dev
  • html - Why are iframes considered dangerous and a security risk? - Stack Overflow
  • xss - How do I safely host third-party Javascript code in an iframe? - Information Security Stack Exchange

Closely related to #89

Depends on the design decision from #176

[tjcouch-sil]

Note #473 and how it may interact with this issue

[tjcouch-sil]

CSP Evaluator
XSS Filter Bypass List
HTML5 Security Cheatsheet

[tjcouch-sil]

PRs:

• Revised content security policy and added WebViewContentType.URL for url webviews #610
• Allow data urls paranext-extension-template#50
• Allow data urls paranext-extension-word-list#5
• Allow data urls paranext-extension-text-collection#18
• Allow data urls paranext-extension-template-hello-world#5