Безопасность

Информирование о проблемах безопасности

Для получения информации о том, как правильно устранять уязвимости Electron, загляни в SECURITY.md.

Что касается уязвимостей в Chromium, обнаруженных ранее: Electron постоянно обновляет информацию о новых версиях Chromium. For more information, see the Electron Release Timelines document.

Предисловие

Как веб-разработчики, мы обычно используем надёжную систему безопасности браузера, а риски, связанные с кодом, что мы пишем, относительно мелкие. Наши веб-сайты имеют ограниченные полномочия в песочнице, и мы верим, что пользователи довольны браузером, созданным большой командой инженеров, которая может быстро реагировать на последние обнаруженные угрозы безопасности.

Когда вы работаете в среде Электрон, важно понимать, что это не веб браузер. Электрон позволяет создавать функционально развитые приложения для настольных компьютеров с помощью веб технологий, но ваш код обладает большими возможностями. JavaScript имеет доступ к файловой системе, пользовательским скриптам и т. д. Благодаря этим возможностям вы можете создавать высококачественные нативные приложения, но это так же множит риски увеличивающиеся с дополнительными полномочиями вашего кода.

Учтите что показ произвольного содержимого от недоверенных источников влечет за собой риски безопасности, которые Электрон не предназначен купировать. Так как фактически, самые популярные приложения Electron (Atom, Slack, Visual Studio Code, и т.д.) отображают в основном локальное содержимое (или доверенное, защищённое удаленное содержимое без интеграции Node), если ваше приложение выполняет код из онлайн-источника, вы обязаны убедиться, что этот код не является вредоносным.

Общие рекомендации

Безопасность — это ответственность каждого

Важно помнить, что безопасность вашего Electron приложения является результатом общей безопасности основы платформы (Chromium, Node.js), самого Electron, всех NPM-зависимостей и вашего кода. Поэтому вы обязаны следовать нескольким важным рекомендациям:

Поддерживайте приложение в актуальном состоянии с помощью последней версии фреймворка Electron. Выпуская свой продукт, вы также поставляете пакет, состоящий из Electron, общей библиотеки Chromium и Node.js. Уязвимости, затрагивающие эти компоненты могут повлиять на безопасность вашего приложения. При обновлении Election до последней версии, будьте уверены, что критические уязвимости (такие, как обход интеграции node) уже исправлены и не могут быть использованы в вашем приложении. For more information, see "Use a current version of Electron".
Оцените свои зависимости. В то время как NPM предоставляет полмиллиона многоразовых пакетов, вы несете ответственность за выбор надежных библиотек третьей стороны. If you use outdated libraries affected by known vulnerabilities or rely on poorly maintained code, your application security could be in jeopardy.
Используйте безопасные методы программирования Первая линия защиты вашей заявки — ваш собственный код. Common web vulnerabilities, such as Cross-Site Scripting (XSS), have a higher security impact on Electron applications hence it is highly recommended to adopt secure software development best practices and perform security testing.

Isolation for untrusted content

Проблемы безопасности возникают всякий раз, когда вы получаете код из ненадежного источника (напр., удаленный сервер) и выполняете его локально. As an example, consider a remote website being displayed inside a default 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.

Предупреждение

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 or a WebContentsView and make sure to disable the nodeIntegration and enable contextIsolation.

Electron security warnings

Security warnings and recommendations are printed to the developer console. They only show up when the binary's name is Electron, indicating that a developer is currently looking at the console.

Вы можете принудительно включить или выключить эти предупреждения в настройках ELECTRON_ENABLE_SECURITY_WARNINGS или ELECTRON_DISABLE_SECURITY_WARNINGS на любом process.env или объекте window.

Checklist: Security recommendations

You should at least follow these steps to improve the security of your application:

Загружайте только безопасный контент
Выключите Node.js интеграцию во всех видах (renderers) показывающих удаленный контент
Enable context isolation in all renderers
Enable process sandboxing
Используйте ses.setPermissionRequestHandler() в сессиях с загрузкой удаленного контента
Не выключайте webSecurity
Определите Content-Security-Policy и используйте ограничительные правила (i.e. script-src 'self')
Не включайте allowRunningInsecureContent
Не включайте экспериментальные функции
Не испольхуйте enableBlinkFeatures
<webview>: Не используйте allowpopups
<webview>: Verify options and params
Disable or limit navigation
Disable or limit creation of new windows
Do not use shell.openExternal with untrusted content
Использовать текущую версию Electron
Validate the sender of all IPC messages
Avoid usage of the file:// protocol and prefer usage of custom protocols
Check which fuses you can change

To automate the detection of misconfigurations and insecure patterns, it is possible to use Electronegativity. For additional details on potential weaknesses and implementation bugs when developing applications using Electron, please refer to this guide for developers and auditors.

1. Загружайте только безопасный контент

Все ресурсы не включенные в ваше приложение должны быть загружены с использованием безопасного протокола HTTPS. Откажитесь от не безопасных протоколов, таких как HTTP. Так же мы рекомендуем WSS over WS, FTPS over FTP, и т. п.

Почему?

HTTPS has two main benefits:

It ensures data integrity, asserting that the data was not modified while in transit between your application and the host.
It encrypts the traffic between your user and the destination host, making it more difficult to eavesdrop on the information sent between your app and the host.

Как?

main.js (Main Process)
// Плохо
browserWindow.loadURL('http://example.com') 

// Хорошо
browserWindow.loadURL('https://example.com')

index.html (Renderer Process)
<!-- Плохо -->
<script crossorigin src="http://example.com/react.js"></script>
<link rel="stylesheet" href="http://example.com/style.css">

<!-- Хорошо -->
<script crossorigin src="https://example.com/react.js"></script>
<link rel="stylesheet" href="https://example.com/style.css">

2. Do not enable Node.js integration for remote content

информация

This recommendation is the default behavior in Electron since 5.0.0.

It is paramount that you do not enable Node.js integration in any renderer (BrowserWindow, WebContentsView, or <webview>) that loads remote content. The goal 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.

After this, you can grant additional permissions for specific hosts. For example, if you are opening a BrowserWindow pointed at https://example.com/, you can give that website exactly the abilities it needs, but no more.

Почему?

A cross-site-scripting (XSS) attack is 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. Disabling Node.js integration helps prevent an XSS from being escalated into a so-called "Remote Code Execution" (RCE) attack.

Как?

main.js (Main Process)
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    contextIsolation: false,
    nodeIntegration: true,
    nodeIntegrationInWorker: true
  }
})

mainWindow.loadURL('https://example.com')

main.js (Main Process)
// Good
const mainWindow = new BrowserWindow({
  webPreferences: {
    preload: path.join(app.getAppPath(), 'preload.js')
  }
})

mainWindow.loadURL('https://example.com')

index.html (Renderer Process)
<!-- Bad -->
<webview nodeIntegration src="page.html"></webview>

<!-- Good -->
<webview src="page.html"></webview>

При отключении интеграции с Node.js, можно по-прежнему использовать API на вашем сайте, которые используют модули или функции Node.js. Preload scripts continue to have access to require and other Node.js features, allowing developers to expose a custom API to remotely loaded content via the contextBridge API.

3. Enable Context Isolation

информация

This recommendation is the default behavior in Electron since 12.0.0.

Context isolation is an Electron feature that allows developers to run code in preload scripts and in Electron APIs in a dedicated JavaScript context. In practice, that means that global objects like Array.prototype.push or JSON.parse cannot be modified by scripts running in the renderer process.

Electron uses the same technology as Chromium's Content Scripts to enable this behavior.

Even when nodeIntegration: false is used, to truly enforce strong isolation and prevent the use of Node primitives contextIsolation must also be used.

информация

For more information on what contextIsolation is and how to enable it please see our dedicated Context Isolation document.

4. Enable process sandboxing

Sandboxing is a Chromium feature that uses the operating system to significantly limit what renderer processes have access to. You should enable the sandbox in all renderers. Loading, reading or processing any untrusted content in an unsandboxed process, including the main process, is not advised.

информация

For more information on what Process Sandboxing is and how to enable it please see our dedicated Process Sandboxing document.

5. Handle session permission requests from remote content

You may have seen permission requests while using Chrome: they pop up whenever the website attempts to use a feature that the user has to manually approve ( like notifications).

The API is based on the Chromium permissions API and implements the same types of permissions.

Почему?

By default, Electron will automatically approve all permission requests unless the developer has manually configured a custom handler. While a solid default, security-conscious developers might want to assume the very opposite.

Как?

main.js (Main Process)
const { session } = require('electron')
const { URL } = require('url')

session
  .fromPartition('some-partition')
  .setPermissionRequestHandler((webContents, permission, callback) => {
    const parsedUrl = new URL(webContents.getURL())

    if (permission === 'notifications') {
      // Approves the permissions request
      callback(true)
    }

    // Verify URL
    if (parsedUrl.protocol !== 'https:' || parsedUrl.host !== 'example.com') {
      // Denies the permissions request
      return callback(false)
    }
  })

6. Не выключайте `webSecurity`

информация

This recommendation is Electron's default.

You may have already guessed that disabling the webSecurity property on a renderer process (BrowserWindow, WebContentsView, or <webview>) disables crucial security features.

Do not disable webSecurity in production applications.

Почему?

Disabling webSecurity will disable the same-origin policy and set allowRunningInsecureContent property to true. In other words, it allows the execution of insecure code from different domains.

Как?

main.js (Main Process)
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    webSecurity: false
  }
})

main.js (Main Process)
// Good
const mainWindow = new BrowserWindow()

index.html (Renderer Process)
<!-- Bad -->
<webview disablewebsecurity src="page.html"></webview>

<!-- Good -->
<webview src="page.html"></webview>

7. Define a Content Security Policy

A Content Security Policy (CSP) is an additional layer of protection against cross-site-scripting attacks and data injection attacks. We recommend that they be enabled by any website you load inside Electron.

Почему?

CSP allows the server serving content to restrict and control the resources Electron can load for that given web page. https://example.com should be allowed to load scripts from the origins you defined while scripts from https://evil.attacker.com should not be allowed to run. Defining a CSP is an easy way to improve your application's security.

Как?

The following CSP will allow Electron to execute scripts from the current website and from apis.example.com.

// Bad
Content-Security-Policy: '*'

// Good
Content-Security-Policy: script-src 'self' https://apis.example.com

CSP HTTP headers

Electron respects the Content-Security-Policy HTTP header which can be set using Electron's webRequest.onHeadersReceived handler:

main.js (Main Process)
const { session } = require('electron')

session.defaultSession.webRequest.onHeadersReceived((details, callback) => {
  callback({
    responseHeaders: {
      ...details.responseHeaders,
      'Content-Security-Policy': ['default-src \'none\'']
    }
  })
})

CSP meta tag

CSP's preferred delivery mechanism is an HTTP header. However, it is not possible to use this method when loading a resource using the file:// protocol. It can be useful in some cases to set a policy on a page directly in the markup using a <meta> tag:

index.html (Renderer Process)
<meta http-equiv="Content-Security-Policy" content="default-src 'none'">

8. Не включайте `allowRunningInsecureContent`

информация

This recommendation is Electron's default.

By default, Electron will not allow websites loaded over HTTPS to load and execute scripts, CSS, or plugins from insecure sources (HTTP). Setting the property allowRunningInsecureContent to true disables that protection.

Loading the initial HTML of a website over HTTPS and attempting to load subsequent resources via HTTP is also known as "mixed content".

Почему?

Loading content over HTTPS assures the authenticity and integrity of the loaded resources while encrypting the traffic itself. See the section on only displaying secure content for more details.

Как?

main.js (Main Process)
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    allowRunningInsecureContent: true
  }
})

main.js (Main Process)
// Good
const mainWindow = new BrowserWindow({})

9. Не включайте экспериментальные функции

информация

This recommendation is Electron's default.

Advanced users of Electron can enable experimental Chromium features using the experimentalFeatures property.

Почему?

Экспериментальные функции, как предлагает название, экспериментальные и не были включены для всех пользователей Chromium. Furthermore, their impact on Electron as a whole has likely not been tested.

Legitimate use cases exist, but unless you know what you are doing, you should not enable this property.

Как?

main.js (Main Process)
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    experimentalFeatures: true
  }
})

main.js (Main Process)
// Good
const mainWindow = new BrowserWindow({})

10. Не испольхуйте `enableBlinkFeatures`

информация

This recommendation is Electron's default.

Blink is the name of the rendering engine behind Chromium. As with experimentalFeatures, the enableBlinkFeatures property allows developers to enable features that have been disabled by default.

Почему?

Generally speaking, there are likely good reasons if a feature was not enabled by default. Legitimate use cases for enabling specific features exist. As a developer, you should know exactly why you need to enable a feature, what the ramifications are, and how it impacts the security of your application. Under no circumstances should you enable features speculatively.

Как?

main.js (Main Process)
// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    enableBlinkFeatures: 'ExecCommandInJavaScript'
  }
})

main.js (Main Process)
// Good
const mainWindow = new BrowserWindow()

11. Не использовать `allowpopups` для WebViews

информация

This recommendation is Electron's default.

If you are using <webview>, you might need the pages and scripts loaded in your <webview> tag to open new windows. The allowpopups attribute enables them to create new BrowserWindows using the window.open() method. <webview> tags are otherwise not allowed to create new windows.

Почему?

If you do not need popups, you are better off not allowing the creation of new BrowserWindows by default. This follows the principle of minimally required access: Don't let a website create new popups unless you know it needs that feature.

Как?

index.html (Renderer Process)
<!-- Bad -->
<webview allowpopups src="page.html"></webview>

<!-- Good -->
<webview src="page.html"></webview>

12. 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 <webview> tags from the main process and to verify that their webPreferences do not disable security features.

Почему?

Since <webview> live in the DOM, they can be created by a script running on your website even if Node.js 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.

Как?

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.

main.js (Main Process)
app.on('web-contents-created', (event, contents) => {
  contents.on('will-attach-webview', (event, webPreferences, params) => {
    // Strip away preload scripts if unused or verify their location is legitimate
    delete webPreferences.preload

    // Disable Node.js integration
    webPreferences.nodeIntegration = false

    // Verify URL being loaded
    if (!params.src.startsWith('https://example.com/')) {
      event.preventDefault()
    }
  })
})

Again, this list merely minimizes the risk, but does not remove it. If your goal is to display a website, a browser will be a more secure option.

If your app has no need to navigate or only needs to navigate to known pages, it is a good idea to limit navigation outright to that known scope, disallowing any other kinds of navigation.

Почему?

Navigation is a common attack vector. If an attacker can convince your app to navigate away from its current page, they can possibly force your app to open web sites on the Internet. Even if your webContents are configured to be more secure (like having nodeIntegration disabled or contextIsolation enabled), getting your app to open a random web site will make the work of exploiting your app a lot easier.

A common attack pattern is that the attacker convinces your app's users to interact with the app in such a way that it navigates to one of the attacker's pages. This is usually done via links, plugins, or other user-generated content.

Как?

If your app has no need for navigation, you can call event.preventDefault() in a will-navigate handler. If you know which pages your app might navigate to, check the URL in the event handler and only let navigation occur if it matches the URLs you're expecting.

We recommend that you use Node's parser for URLs. Simple string comparisons can sometimes be fooled - a startsWith('https://example.com') test would let https://example.com.attacker.com through.

main.js (Main Process)
const { URL } = require('url')
const { app } = require('electron')

app.on('web-contents-created', (event, contents) => {
  contents.on('will-navigate', (event, navigationUrl) => {
    const parsedUrl = new URL(navigationUrl)

    if (parsedUrl.origin !== 'https://example.com') {
      event.preventDefault()
    }
  })
})

14. Disable or limit creation of new windows

If you have a known set of windows, it's a good idea to limit the creation of additional windows in your app.

Почему?

Much like navigation, the creation of new webContents is a common attack vector. Attackers attempt to convince your app to create new windows, frames, or other renderer processes with more privileges than they had before; or with pages opened that they couldn't open before.

If you have no need to create windows in addition to the ones you know you'll need to create, disabling the creation buys you a little bit of extra security at no cost. This is commonly the case for apps that open one BrowserWindow and do not need to open an arbitrary number of additional windows at runtime.

Как?

webContents will delegate to its window open handler before creating new windows. The handler will receive, amongst other parameters, the url the window was requested to open and the options used to create it. We recommend that you register a handler to monitor the creation of windows, and deny any unexpected window creation.

main.js (Main Process)
const { app, shell } = require('electron')

app.on('web-contents-created', (event, contents) => {
  contents.setWindowOpenHandler(({ url }) => {
    // In this example, we'll ask the operating system
    // to open this event's url in the default browser.
    //
    // See the following item for considerations regarding what
    // URLs should be allowed through to shell.openExternal.
    if (isSafeForExternalOpen(url)) {
      setImmediate(() => {
        shell.openExternal(url)
      })
    }

    return { action: 'deny' }
  })
})

15. Do not use `shell.openExternal` with untrusted content

The shell module's openExternal API allows opening a given protocol URI with the desktop's native utilities. On macOS, for instance, this function is similar to the open terminal command utility and will open the specific application based on the URI and filetype association.

Почему?

Improper use of openExternal can be leveraged to compromise the user's host. When openExternal is used with untrusted content, it can be leveraged to execute arbitrary commands.

Как?

main.js (Main Process)
//  Bad
const { shell } = require('electron')
shell.openExternal(USER_CONTROLLED_DATA_HERE)

main.js (Main Process)
//  Good
const { shell } = require('electron')
shell.openExternal('https://example.com/index.html')

16. Использовать текущую версию Electron

You should strive for always using the latest available version of Electron. Whenever a new major version is released, you should attempt to update your app as quickly as possible.

Почему?

An application built with an older version of Electron, Chromium, and Node.js is an easier target than an application that is using more recent versions of those components. Generally speaking, security issues and exploits for older versions of Chromium and Node.js are more widely available.

Both Chromium and Node.js are impressive feats of engineering built by thousands of talented developers. Given their popularity, their security is carefully tested and analyzed by equally skilled security researchers. Many of those researchers disclose vulnerabilities responsibly, which generally means that researchers will give Chromium and Node.js some time to fix issues before publishing them. Your application will be more secure if it is running a recent version of Electron (and thus, Chromium and Node.js) for which potential security issues are not as widely known.

Как?

Migrate your app one major version at a time, while referring to Electron's Breaking Changes document to see if any code needs to be updated.

17. Validate the `sender` of all IPC messages

You should always validate incoming IPC messages sender property to ensure you aren't performing actions or sending information to untrusted renderers.

Почему?

All Web Frames can in theory send IPC messages to the main process, including iframes and child windows in some scenarios. If you have an IPC message that returns user data to the sender via event.reply or performs privileged actions that the renderer can't natively, you should ensure you aren't listening to third party web frames.

You should be validating the sender of all IPC messages by default.

Как?

main.js (Main Process)
// Bad
ipcMain.handle('get-secrets', () => {
  return getSecrets()
})

// Good
ipcMain.handle('get-secrets', (e) => {
  if (!validateSender(e.senderFrame)) return null
  return getSecrets()
})

function validateSender (frame) {
  // Value the host of the URL using an actual URL parser and an allowlist
  if ((new URL(frame.url)).host === 'electronjs.org') return true
  return false
}

18. Avoid usage of the `file://` protocol and prefer usage of custom protocols

You should serve local pages from a custom protocol instead of the file:// protocol.

Почему?

The file:// protocol gets more privileges in Electron than in a web browser and even in browsers it is treated differently to http/https URLs. Using a custom protocol allows you to be more aligned with classic web url behavior while retaining even more control about what can be loaded and when.

Pages running on file:// have unilateral access to every file on your machine meaning that XSS issues can be used to load arbitrary files from the users machine. Using a custom protocol prevents issues like this as you can limit the protocol to only serving a specific set of files.

Как?

Follow the protocol.handle examples to learn how to serve files / content from a custom protocol.

19. Check which fuses you can change

Electron ships with a number of options that can be useful but a large portion of applications probably don't need. In order to avoid having to build your own version of Electron, these can be turned off or on using Fuses.

Почему?

Some fuses, like runAsNode and nodeCliInspect, allow the application to behave differently when run from the command line using specific environment variables or CLI arguments. These can be used to execute commands on the device through your application.

This can let external scripts run commands that they potentially would not be allowed to, but that your application might have the rights for.

Как?

We've made a module, @electron/fuses, to make flipping these fuses easy. Check out the README of that module for more details on usage and potential error cases, and refer to How do I flip the fuses? in our documentation.

Предисловие​

Общие рекомендации​

Безопасность — это ответственность каждого​

Isolation for untrusted content​

Checklist: Security recommendations​

1. Загружайте только безопасный контент​

Почему?​

Как?​

2. Do not enable Node.js integration for remote content​

Почему?​

Как?​

3. Enable Context Isolation​

4. Enable process sandboxing​

5. Handle session permission requests from remote content​

Почему?​

Как?​

6. Не выключайте webSecurity​

Почему?​

Как?​

7. Define a Content Security Policy​

Почему?​

Как?​

CSP HTTP headers​

CSP meta tag​

8. Не включайте allowRunningInsecureContent​

Почему?​

Как?​

9. Не включайте экспериментальные функции​

Почему?​

Как?​

10. Не испольхуйте enableBlinkFeatures​

Почему?​

Как?​

11. Не использовать allowpopups для WebViews​

Почему?​

Как?​

12. Verify WebView options before creation​

Почему?​

Как?​

13. Disable or limit navigation​

Почему?​

Как?​

14. Disable or limit creation of new windows​

Почему?​

Как?​

15. Do not use shell.openExternal with untrusted content​

Почему?​

Как?​

16. Использовать текущую версию Electron​

Почему?​

Как?​

17. Validate the sender of all IPC messages​

Почему?​

Как?​

18. Avoid usage of the file:// protocol and prefer usage of custom protocols​

Почему?​

Как?​

19. Check which fuses you can change​

Почему?​

Как?​

Предисловие

Общие рекомендации

Безопасность — это ответственность каждого

Isolation for untrusted content

Checklist: Security recommendations

1. Загружайте только безопасный контент

Почему?

Как?

2. Do not enable Node.js integration for remote content

Почему?

Как?

3. Enable Context Isolation

4. Enable process sandboxing

5. Handle session permission requests from remote content

Почему?

Как?

6. Не выключайте `webSecurity`

Почему?

Как?

7. Define a Content Security Policy

Почему?

Как?

CSP HTTP headers

CSP meta tag

8. Не включайте `allowRunningInsecureContent`

Почему?

Как?

9. Не включайте экспериментальные функции

Почему?

Как?

10. Не испольхуйте `enableBlinkFeatures`

Почему?

Как?

11. Не использовать `allowpopups` для WebViews

Почему?

Как?

12. Verify WebView options before creation

Почему?

Как?

13. Disable or limit navigation

Почему?

Как?

14. Disable or limit creation of new windows

Почему?

Как?

15. Do not use `shell.openExternal` with untrusted content

Почему?

Как?

16. Использовать текущую версию Electron

Почему?

Как?

17. Validate the `sender` of all IPC messages

Почему?

Как?

18. Avoid usage of the `file://` protocol and prefer usage of custom protocols

Почему?

Как?

19. Check which fuses you can change

Почему?

Как?