📝 General cleanup
This commit is contained in:
Felix Rieseberg
parent
c4dc8dacbf
commit
fb8606dd0c
1 changed files with 77 additions and 64 deletions
|
|
@ -1,19 +1,19 @@
|
|||
# Security, Native Capabilities, and Your Responsibility
|
||||
|
||||
As web developers, we usually enjoy the strong security net of the browser - the
|
||||
risks associated with the code we write are relatively small. Our websites are
|
||||
granted limited powers in a sandbox, and we trust that our users enjoy a browser
|
||||
built by a large team of engineers that is able to quickly respond to newly
|
||||
discovered security threats.
|
||||
As web developers, we usually enjoy the strong security net of the browser -
|
||||
the risks associated with the code we write are relatively small. Our websites
|
||||
are granted limited powers in a sandbox, and we trust that our users enjoy a
|
||||
browser built by a large team of engineers that is able to quickly respond to
|
||||
newly discovered security threats.
|
||||
|
||||
When working with Electron, it is important to understand that Electron is not
|
||||
a web browser. It allows you to build feature-rich desktop applications with
|
||||
familiar web technologies, but your code wields much greater power. JavaScript
|
||||
can access the filesystem, user shell, and more. This allows you to build
|
||||
high quality native applications, but the inherent security risks scale with the
|
||||
additional powers granted to your code.
|
||||
high quality native applications, but the inherent security risks scale with
|
||||
the additional powers granted to your code.
|
||||
|
||||
With that in mind, be aware that displaying arbitrary content from untrusted
|
||||
With that in mind, be aware that displaying arbitrary content from un-trusted
|
||||
sources poses a severe security risk that Electron is not intended to handle.
|
||||
In fact, the most popular Electron apps (Atom, Slack, Visual Studio Code, etc)
|
||||
display primarily local content (or trusted, secure remote content without Node
|
||||
|
|
@ -34,8 +34,8 @@ contributions available today, Electron will often not be on the very latest
|
|||
version of Chromium, lagging behind by either days or weeks.
|
||||
|
||||
We feel that our current system of updating the Chromium component strikes an
|
||||
appropriate balance between the resources we have available and the needs of the
|
||||
majority of applications built on top of the framework. We definitely are
|
||||
appropriate balance between the resources we have available and the needs of
|
||||
the majority of applications built on top of the framework. We definitely are
|
||||
interested in hearing more about specific use cases from the people that build
|
||||
things on top of Electron. Pull requests and contributions supporting this
|
||||
effort are always very welcome.
|
||||
|
|
@ -44,15 +44,15 @@ effort are always very welcome.
|
|||
|
||||
A security issue exists whenever you receive code from a remote destination and
|
||||
execute it locally. As an example, consider a remote website being displayed
|
||||
inside a browser window. If an attacker somehow manages to change said content
|
||||
inside a `BrowserWindow`. If an attacker somehow manages to change said content
|
||||
(either by attacking the source directly, or by sitting between your app and
|
||||
the actual destination), they will be able to execute native code on the user's
|
||||
machine.
|
||||
|
||||
> :warning: Under no circumstances should you load and execute remote code with
|
||||
Node.js integration enabled. Instead, use only local files (packaged together with
|
||||
your application) to execute Node.js code. To display remote content, use the
|
||||
`webview` tag and make sure to disable the `nodeIntegration`.
|
||||
Node.js integration enabled. Instead, use only local files (packaged together
|
||||
with your application) to execute Node.js code. To display remote content, use
|
||||
the `webview` tag and make sure to disable the `nodeIntegration`.
|
||||
|
||||
#### Checklist: Security Recommendations
|
||||
|
||||
|
|
@ -60,39 +60,34 @@ This is not bulletproof, but at the least, you should attempt the following:
|
|||
|
||||
* [Only display secure (https) content](#only-display-secure-content)
|
||||
* [Disable the Node integration in all renderers that display remote content](#disable-node-integration-for-remote-content)
|
||||
(setting `nodeIntegration` to `false` in `webPreferences`)
|
||||
* Enable context isolation in all renderers that display remote content
|
||||
(setting `contextIsolation` to `true` in `webPreferences`)
|
||||
* Use `ses.setPermissionRequestHandler()` in all sessions that load remote content
|
||||
* Do not disable `webSecurity`. Disabling it will disable the same-origin policy.
|
||||
* Define a [`Content-Security-Policy`](http://www.html5rocks.com/en/tutorials/security/content-security-policy/)
|
||||
* [Enable context isolation in all renderers that display remote content](#enable-context-isolation-for-remote-content)
|
||||
* [Use `ses.setPermissionRequestHandler()` in all sessions that load remote content](#handle-session-permission-requests-from-remote-content)
|
||||
* [Do not disable `webSecurity`](#do-not-disable-websecurity)
|
||||
* [Define a `Content-Security-Policy`](#define-a-content-security-policy)
|
||||
, and use restrictive rules (i.e. `script-src 'self'`)
|
||||
* [Override and disable `eval`](https://github.com/nylas/N1/blob/0abc5d5defcdb057120d726b271933425b75b415/static/index.js#L6-L8)
|
||||
* [Override and disable `eval`](#override-and-disable)
|
||||
, which allows strings to be executed as code.
|
||||
* Do not set `allowRunningInsecureContent` to true.
|
||||
* Do not enable `experimentalFeatures` or `experimentalCanvasFeatures` unless
|
||||
you know what you're doing.
|
||||
* Do not use `blinkFeatures` unless you know what you're doing.
|
||||
* WebViews: Do not add the `nodeintegration` attribute.
|
||||
* WebViews: Do not use `disablewebsecurity`
|
||||
* WebViews: Do not use `allowpopups`
|
||||
* WebViews: Do not use `insertCSS` or `executeJavaScript` with remote CSS/JS.
|
||||
* [Do not set `allowRunningInsecureContent` to `true`](#do-not-set-allowRunningInsecureContent-to-true)
|
||||
* [Do not enable experimental features](#do-not-enable-enable-experimental-features)
|
||||
* [Do not use `blinkFeatures`](#do-not-use-blinkfeatures)
|
||||
* [WebViews: Do not use `allowpopups`](#do-not-use-allowpopups)
|
||||
* [WebViews: Verify the options and params of all `<webview>` tags](#verify-webview-options-before-creation)
|
||||
|
||||
|
||||
## Only Display Secure Content
|
||||
Any resources not included with your application should be loaded using a secure
|
||||
protocol like `HTTPS`. Furthermore, avoid "mixed content", which occurs when the
|
||||
initial HTML is loaded over an `HTTPS` connection, but additional resources
|
||||
(scripts, stylesheets, etc) are loaded over an insecure connection.
|
||||
|
||||
Any resources not included with your application should be loaded using a
|
||||
secure protocol like `HTTPS`.
|
||||
|
||||
### Why?
|
||||
|
||||
`HTTPS` has three main benefits:
|
||||
|
||||
1) It authenticates the remote server, ensuring that the host is actually who it
|
||||
claims to be. When loading a resource from an `HTTPS` host, it prevents an
|
||||
attacker from impersonating that host, thus ensuring that the computer your
|
||||
app's users are connecting to is actually the host you wanted them to connect
|
||||
to.
|
||||
1) It authenticates the remote server, ensuring that the host is actually who
|
||||
it claims to be. When loading a resource from an `HTTPS` host, it prevents
|
||||
an attacker from impersonating that host, thus ensuring that the computer
|
||||
your app's users are connecting to is actually the host you wanted them to
|
||||
connect to.
|
||||
2) It ensures data integrity, asserting that the data was not modified while in
|
||||
transit between your application and the host.
|
||||
3) It encryps the traffic between your user and the destination host, making it
|
||||
|
|
@ -100,6 +95,7 @@ initial HTML is loaded over an `HTTPS` connection, but additional resources
|
|||
the host.
|
||||
|
||||
### How?
|
||||
|
||||
```js
|
||||
// Bad
|
||||
browserWindow.loadURL('http://my-website.com')
|
||||
|
|
@ -118,29 +114,33 @@ browserWindow.loadURL('https://my-website.com')
|
|||
<link rel="stylesheet" href="https://cdn.com/style.css">
|
||||
```
|
||||
|
||||
## Disable Node Integration for Remote Content
|
||||
It is paramount that you disable Node integration in any renderer (`BrowserWindow`,
|
||||
`BrowserView`, or `WebView`) that loads remote content. The goal of disabling Node
|
||||
integration is to limit the powers you grant to remote content, thus making it
|
||||
dramatically more difficult for an attacker to harm your users should they gain
|
||||
the ability to execute JavaScript on your website.
|
||||
|
||||
Disabling Node integration does not mean that you cannot grant additional powers
|
||||
to the website you are loading. If you are opening a `BrowserWindow` pointed at
|
||||
`https://my-website.com`, the goal is to give that website exactly the abilities
|
||||
it needs, but no more.
|
||||
## Disable Node Integration for Remote Content
|
||||
|
||||
It is paramount that you disable Node integration in any renderer
|
||||
(`BrowserWindow`, `BrowserView`, or `WebView`) that loads remote content. The
|
||||
goal of disabling Node integration is to limit the powers you grant to remote
|
||||
content, thus making it dramatically more difficult for an attacker to harm
|
||||
your users should they gain the ability to execute JavaScript on your website.
|
||||
|
||||
Disabling Node integration does not mean that you cannot grant additional
|
||||
powers to the website you are loading. If you are opening a `BrowserWindow`
|
||||
pointed at `https://my-website.com`, the goal is to give that website exactly
|
||||
the abilities it needs, but no more.
|
||||
|
||||
### Why?
|
||||
|
||||
A cross-site-scripting (XSS) attack becomes dramatically more dangerous if an
|
||||
attacker can jump out of the renderer process and execute code on the user's
|
||||
computer. Cross-site-scripting attacks are fairly common - and while an issue,
|
||||
their power is usually limited to messing with the website that they are executed
|
||||
on. However, in a renderer process with Node.js integration enabled, an XSS attack
|
||||
becomes a whole different class of attack: A so-called "Remote Code Execution"
|
||||
(RCE) attack. Disabling Node.js integration limits the power of successful XSS
|
||||
attacks.
|
||||
their power is usually limited to messing with the website that they are
|
||||
executed on. However, in a renderer process with Node.js integration enabled,
|
||||
an XSS attack becomes a whole different class of attack: A so-called "Remote
|
||||
Code Execution" (RCE) attack. Disabling Node.js integration limits the power
|
||||
of successful XSS attacks.
|
||||
|
||||
### How?
|
||||
|
||||
```js
|
||||
// Bad
|
||||
const mainWindow = new BrowserWindow()
|
||||
|
|
@ -157,13 +157,21 @@ const mainWindow = new BrowserWindow({
|
|||
mainWindow.loadURL('https://my-website.com')
|
||||
```
|
||||
|
||||
When disabling Node integration, you can still expose APIs to your
|
||||
website that do consume Node.js modules or features. Preload scripts continue to
|
||||
have access to `require` and other Node.js features, allowing developers to expose
|
||||
a custom API to remotely loaded content.
|
||||
```html
|
||||
<!-- Bad -->
|
||||
<webview nodeIntegration src="page.html"></webview>
|
||||
|
||||
In the following example preload script, the later loaded website will have access
|
||||
to a `window.readConfig()` method, but no Node.js features.
|
||||
<!-- Good -->
|
||||
<webview src="page.html"></webview>
|
||||
```
|
||||
|
||||
When disabling Node integration, you can still expose APIs to your website that
|
||||
do consume Node.js modules or features. Preload scripts continue to have access
|
||||
to `require` and other Node.js features, allowing developers to expose a custom
|
||||
API to remotely loaded content.
|
||||
|
||||
In the following example preload script, the later loaded website will have
|
||||
access to a `window.readConfig()` method, but no Node.js features.
|
||||
|
||||
```js
|
||||
const { readFileSync } = require('fs')
|
||||
|
|
@ -231,6 +239,7 @@ document.addEventListener('DOMContentLoaded', () => {
|
|||
})
|
||||
```
|
||||
|
||||
|
||||
## Handle Session Permission Requests From Remote Content
|
||||
|
||||
You may have seen permission requests while using Chrome: They pop up whenever
|
||||
|
|
@ -476,23 +485,27 @@ the ability to create new popups.
|
|||
|
||||
|
||||
## Verify WebView Options Before Creation
|
||||
|
||||
A WebView created in a renderer process that does not have Node.js integration
|
||||
enabled will not be able to enable integration itself. However, a WebView will
|
||||
always create an independent renderer process with its own `webPreferences`.
|
||||
|
||||
It is a good idea to control the creation of new `WebViews` from the main process
|
||||
and to verify that their webPreferences do not disable security features.
|
||||
It is a good idea to control the creation of new `WebViews` from the main
|
||||
process and to verify that their webPreferences do not disable security
|
||||
features.
|
||||
|
||||
### Why?
|
||||
|
||||
Since WebViews live in the DOM, they can be created by a script running on your
|
||||
website even if Node integration is otherwise disabled.
|
||||
|
||||
Electron enables developers to disable various security features that control
|
||||
a renderer process. In most cases, developers do not need to disable any of those
|
||||
features - and you should therefore not allow different configurations for newly
|
||||
created `<WebView>` tags.
|
||||
a renderer process. In most cases, developers do not need to disable any of
|
||||
those features - and you should therefore not allow different configurations
|
||||
for newly created `<WebView>` tags.
|
||||
|
||||
### How?
|
||||
|
||||
Before a `<WebView>` tag is attached, Electron will fire the
|
||||
`will-attach-webview` event on the hosting `webContents`. Use the event to
|
||||
prevent the creation of WebViews with possibly insecure options.
|
||||
|
|
|
|||
Loading…
Reference in a new issue