Implement Electron security guidelines

[amaury1093]

Electron has a 12-point checklist called "Security, Native Capabilities, and Your Responsibility". Parity UI should follow those guidelines.

• Only load secure content
• Disable the Node.js integration in all renderers that display remote content
• Enable context isolation in all renderers that display remote content.
• Use ses.setPermissionRequestHandler() in all sessions that load remote content
• Do not disable webSecurity
• Define a Content-Security-Policy and use restrictive rules (i.e. script-src 'self').
• Override and disable eval, which allows strings to be executed as code. Not enabling this one as Web3 Console dapp needs eval(). However all networks dapps disallow eval() in their CSP, so we actually don't need this.
• Do not set allowRunningInsecureContent to true
• Do not enable experimental features
• Do not use blinkFeatures
• WebViews: Do not use allowpopups
• WebViews: Verify the options and params of all tags

Also removing the proxy to /parity-utils, so that the only inject.js the dapps are receiving now is the one injected by Electron.

[amaury1093]

"3. Enable context isolation in all renderers that display remote content" needs some explanation (for future reference).

TL;DR There are some gymnastics to do in order to have Parity UI follow all these guidelines.

Without contextIsolation (i.e. before this PR), I did:

// In inject.js
window.ethereum = ...;

// In dapp
console.log(window.ethereum); // Will print something

With contextIsolation, we now have:

// In inject.js
window.ethereum = ...;

// In dapp
console.log(window.ethereum); // undefined, because preload and dapp do not share context
// Also, dapp cannot send IPC message to shell anymore (due to no nodeintegration)

1. How to inject window.ethereum in the dapp?
2. How to make dapp and shell communicate? IPC and postMessage don't work between those two.

---

Solution

1. Easy, a preload script can call webFrame.executeJavaScript(...). So instead of injecting directly inject.js (which wouldn't work because of above), we inject preload.js, which will do webFrame.executeJavaScript(/* the content of inject.js as a huge string*/). Hence the introduction of preload.js.

2. After asking here the solution seems to be having preload.js as a proxy:

Electron <---IPC---> preload.js <---postMessage---> dapp

Because the shell can't communicate with the dapp via postMessage nor IPC. But the shell can communicate with preload.js via IPC, and the dapp can communicate with preload.js via postMessage. So preload.js acts as a message relayer.

[jacogr]

It looks sane, it feels sane when running - however worried that there may be edge-cases I have not seen with "doing some dapp stuff" testing.

It would be good to get a bit wider testing with binaries.

[axelchalon]

url refers to the library here. You forgot: const url = webContents.getURL()

[amaury1093]

F*ck... Nice catch, thanks!

[axelchalon]

Could we use getBuildPath() from src/util/host.js here?

[amaury1093]

Unfortunately not, I was getting a window.require is not a function.

Reason is: in preload.js, isElectron() is true, however it's not a renderer process so you would do require('electron') instead of window.require('electron')

[axelchalon]

Seems to be working fine! HoweverParity/Web3 console dapp (tried on kovan) doesn't seem to work anymore: Error: Sorry, this app does not support window.eval().