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

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

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

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

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

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

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

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

• Поддерживайте своё приложение в актуальном состоянии, используя последнюю версию фреймворка Electron. При выпуске вашего продукта вы также распространяете набор, включающий Electron, общую библиотеку Chromium и Node.js. Уязвимости, влияющие на эти компоненты, могут повлиять на безопасность вашего приложения. Обновление Electron до последней версии гарантирует, что критические уязвимости (например, nodeIntegration bypasses) уже исправлены и не могут быть использованы в вашем приложении. Дополнительную информацию можно найти в разделе «Используйте актуальную версию Electron».

• Оценивайте свои зависимости. Хотя NPM предоставляет полмиллиона пакетов для повторного использования, вы несёте ответственность за выбор надёжных библиотек третьих сторон. Если вы используете устаревшие библиотеки, подверженные известным уязвимостям, или полагаетесь на плохо поддерживаемый код, безопасность вашего приложения может быть поставлена под угрозу.

• Применяйте безопасные методы программирования. Первая линия защиты вашего приложения — это ваш собственный код. Общие веб-уязвимости, такие как межсайтовый скриптинг (XSS), имеют более высокий уровень воздействия на приложения Electron, поэтому настоятельно рекомендуется применять лучшие практики разработки безопасного программного обеспечения и проводить тестирование на безопасность.

Изоляция недоверенного содержимого​

Проблема безопасности возникает всякий раз, когда вы получаете код из недоверенного источника (например, удалённого сервера) и выполняете его локально. Например, рассмотрим удалённый веб-сайт, отображаемый внутри стандартного BrowserWindow. Если злоумышленник каким-то образом сумеет изменить это содержимое (либо атакуя источник напрямую, либо находясь между вашим приложением и фактическим пунктом назначения), он сможет выполнить нативный код на компьютере пользователя.

Список проверок: рекомендации по безопасности​

Для повышения безопасности приложения следует выполнить как минимум следующие шаги:

1. Загружать только защищённое содержимое
2. Отключить интеграцию Node.js для всех рендереров, отображающих удалённое содержимое
3. Включить изоляцию контекста во всех рендерерах
4. Включить песочницу процессов
5. Использовать ses.setPermissionRequestHandler() во всех сессиях, загружающих удалённое содержимое
6. Не отключать webSecurity
7. Определить Content-Security-Policy и использовать жёсткие правила (например, script-src 'self')
8. Не включать allowRunningInsecureContent
9. Не включать экспериментальные функции
10. Не использовать enableBlinkFeatures
11. <webview>: Не использовать allowpopups
12. <webview>: Проверять параметры и опции
13. Отключить или ограничить навигацию
14. Отключить или ограничить создание новых окон
15. Не использовать shell.openExternal с недоверенным содержимым
16. Использовать актуальную версию Electron

Для автоматизации обнаружения неправильных конфигураций и небезопасных шаблонов можно использовать Electronegativity. Для получения дополнительной информации о потенциальных уязвимостях и ошибках реализации при разработке приложений с использованием Electron, обратитесь к этому руководству для разработчиков и аудиторов.

1. Загружать только защищённое содержимое​

Любые ресурсы, не включённые в ваше приложение, должны загружаться с использованием защищённого протокола, например, HTTPS. Другими словами, не используйте небезопасные протоколы, такие как HTTP. Аналогично, мы рекомендуем использовать WSS вместо WS, FTPS вместо FTP и так далее.

Почему?​

HTTPS имеет три основных преимущества:

1. Он аутентифицирует удалённый сервер, гарантируя, что ваше приложение подключается к нужному хосту, а не к подделке.
2. Он гарантирует целостность данных, подтверждая, что данные не были изменены во время передачи между вашим приложением и хостом.
3. Он шифрует трафик между вашим пользователем и хостом назначения, что затрудняет перехват информации, передаваемой между вашим приложением и хостом.

Как?​

// Bad
browserWindow.loadURL('http://example.com')

// Good
browserWindow.loadURL('https://example.com')

<!-- Bad -->
<script crossorigin src="http://example.com/react.js"></script>
<link rel="stylesheet" href="http://example.com/style.css">

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

2. Не включать интеграцию Node.js для удалённого содержимого​

Крайне важно не включать интеграцию Node.js ни в одном рендерере (BrowserWindow, BrowserView или <webview>), загружающем удалённое содержимое. Цель состоит в том, чтобы ограничить полномочия удалённого содержимого, что значительно затрудняет злоумышленнику нанести вред вашим пользователям, если у него появится возможность выполнять JavaScript на вашем веб-сайте.

После этого вы можете предоставить дополнительные разрешения для конкретных хостов. Например, если вы открываете BrowserWindow, указав https://example.com/, вы можете предоставить этому веб-сайту ровно те возможности, которые ему необходимы, но не больше.

Почему?​

Атака с межсайтовым скриптингом (XSS) более опасна, если злоумышленник может выйти за пределы процесса рендеринга и выполнить код на компьютере пользователя. Атаки с межсайтовым скриптингом довольно распространены, и, хотя это проблема, их возможности обычно ограничены вмешательством в работу веб-сайта, на котором они выполняются. Отключение интеграции Node.js помогает предотвратить эскалацию XSS в атаку с удалённым выполнением кода (RCE).

Как?​

// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    contextIsolation: false,
    nodeIntegration: true,
    nodeIntegrationInWorker: true
  }
})

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

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

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

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

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

При отключении интеграции Node.js вы по-прежнему можете предоставлять API для вашего сайта, которые используют модули или возможности Node.js. Скрипты предварительной загрузки по-прежнему имеют доступ к require и другим функциям Node.js, что позволяет разработчикам экспонировать пользовательский API для удалённого содержимого через API contextBridge.

3. Включить изоляцию контекста​

Изоляция контекста — это функция Electron, которая позволяет разработчикам запускать код в скриптах предварительной загрузки и в Electron API в выделенном контексте JavaScript. На практике это означает, что глобальные объекты, такие как Array.prototype.push или JSON.parse, не могут быть изменены скриптами, выполняющимися в процессе рендеринга.

Electron использует ту же технологию, что и Content Scripts в Chromium's Content Scripts для включения этого поведения.

Даже когда используется nodeIntegration: false, для обеспечения строгой изоляции и предотвращения использования примитивов Node contextIsolation обязательно должно использоваться.

4. Включить песочницу процесса​

Песочница — это функция Chromium, которая использует операционную систему для существенного ограничения доступа процессов рендеринга. Вам следует включить песочницу во всех процессах рендеринга. Загрузка, чтение или обработка любого недоверенного содержимого в незащищённом процессе, включая основной процесс, не рекомендуется.

5. Обработка запросов на разрешение сессии от удалённого содержимого​

Вы могли видеть запросы на разрешения при использовании Chrome: они появляются всякий раз, когда веб-сайт пытается использовать функцию, которую пользователь должен одобрить вручную (например, уведомления).

API основано на API разрешений Chromium и реализует те же типы разрешений.

Почему?​

По умолчанию Electron автоматически одобряет все запросы на разрешения, если разработчик не настроился на пользовательскую обработку. Хотя это надёжное значение по умолчанию, разработчики, ориентирующиеся на безопасность, могут захотеть предположить обратное.

Как?​

const { session } = require('electron')
const URL = require('url').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.​

Вы, возможно, уже догадались, что отключение свойства webSecurity в процессе рендеринга (BrowserWindow, BrowserView или <webview>) отключает важные функции безопасности.

Не отключайте webSecurity в приложениях в рабочей среде.

Почему?​

Отключение webSecurity отключит политику одинакового происхождения и установит свойство allowRunningInsecureContent в значение true. Другими словами, это позволит выполнять небезопасный код из различных доменов.

Как?​

// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    webSecurity: false
  }
})

// Good
const mainWindow = new BrowserWindow()

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

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

7. Определить политику безопасности содержимого​

Политика безопасности содержимого (CSP) — это дополнительный уровень защиты от атак с межсайтовым скриптингом и атак с инъекцией данных. Мы рекомендуем включить их на любом веб-сайте, который вы загружаете в Electron.

Почему?​

CSP позволяет серверу, предоставляющему содержимое, ограничивать и контролировать ресурсы, которые Electron может загружать для данной веб-страницы. https://example.com должен иметь возможность загружать скрипты из определённых вами источников, в то время как скрипты из https://evil.attacker.com не должны выполняться. Определение CSP — простой способ повышения безопасности вашего приложения.

Как?​

Следующая CSP позволит Electron выполнять скрипты с текущего сайта и с apis.example.com.

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

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

Заголовки CSP HTTP​

Electron учитывает заголовок HTTP Content-Security-Policy, который может быть установлен с помощью обработчика webRequest.onHeadersReceived Electron:

const { session } = require('electron')

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

Тег meta CSP​

Предпочтительный способ передачи CSP — это HTTP-заголовок. Однако этот метод нельзя использовать при загрузке ресурса с протоколом file://. В некоторых случаях полезно задавать политику непосредственно на странице в разметке с помощью тега <meta>.

<meta http-equiv="Content-Security-Policy" content="default-src 'none'">

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

По умолчанию Electron не разрешает веб-сайтам, загруженным по протоколу HTTPS, загружать и выполнять скрипты, CSS или плагины из небезопасных источников (HTTP). Установка свойства allowRunningInsecureContent в значение true отключает эту защиту.

Загрузка начального HTML веб-сайта по протоколу HTTPS и попытка загрузить последующие ресурсы по протоколу HTTP также известны как «смешанное содержимое».

Почему?​

Загрузка содержимого через HTTPS гарантирует подлинность и целостность загруженных ресурсов, а также шифрует сам трафик. Более подробную информацию см. в разделе только отображение защищенного содержимого.

Как?​

// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    allowRunningInsecureContent: true
  }
})

// Good
const mainWindow = new BrowserWindow({})

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

Расширенные пользователи Electron могут включить экспериментальные функции Chromium, используя свойство experimentalFeatures.

Почему?​

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

Существуют законные случаи использования, но если вы не знаете, что делаете, не следует включать это свойство.

Как?​

// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    experimentalFeatures: true
  }
})

// Good
const mainWindow = new BrowserWindow({})

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

Blink — это движок рендеринга, лежащий в основе Chromium. Как и experimentalFeatures, свойство enableBlinkFeatures позволяет разработчикам включать функции, которые по умолчанию отключены.

Почему?​

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

Как?​

// Bad
const mainWindow = new BrowserWindow({
  webPreferences: {
    enableBlinkFeatures: 'ExecCommandInJavaScript'
  }
})

// Good
const mainWindow = new BrowserWindow()

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

Если вы используете <webview>, вам, возможно, потребуется, чтобы страницы и скрипты, загруженные в вашем теге <webview>, открывали новые окна. Атрибут allowpopups позволяет им создавать новые BrowserWindows с помощью метода window.open(). В противном случае теги <webview> не могут создавать новые окна.

Почему?​

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

Как?​

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

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

12. Проверьте параметры WebView перед созданием​

WebView, созданный в процессе рендеринга, в котором отключена интеграция с Node.js, не сможет включить интеграцию самостоятельно. Однако WebView всегда создает независимый процесс рендеринга со своим собственным webPreferences.

Рекомендуется контролировать создание новых тегов <webview> из основного процесса и проверять, что их webPreferences не отключают функции безопасности.

Почему?​

Поскольку <webview> находятся в DOM, их может создать сценарий, выполняющийся на вашем веб-сайте, даже если интеграция с Node.js в противном случае отключена.

Electron позволяет разработчикам отключать различные функции безопасности, которые контролируют процесс рендеринга. В большинстве случаев разработчикам не нужно отключать ни одну из этих функций — и поэтому вы не должны разрешать различные конфигурации для вновь созданных тегов <webview>.

Как?​

Перед прикреплением тега <webview>, Electron сгенерирует событие will-attach-webview в принимающем webContents. Используйте событие, чтобы предотвратить создание webViews с потенциально небезопасными параметрами.

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()
    }
  })
})

Опять же, этот список лишь сводит к минимуму риск, но не устраняет его. Если ваша цель — отобразить веб-сайт, браузер будет более безопасным вариантом.

13. Отключить или ограничить навигацию​

Если в вашем приложении нет необходимости в навигации или требуется навигация только по известным страницам, рекомендуется ограничить навигацию исключительно этим известным объемом, запретив любые другие виды навигации.

Почему?​

Навигация — это распространенный вектор атак. Если злоумышленник может убедить ваше приложение перейти от текущей страницы, он может заставить ваше приложение открыть веб-сайты в Интернете. Даже если ваши webContents сконфигурированы более безопасно (например, если отключено nodeIntegration или включено contextIsolation), заставить ваше приложение открыть случайный веб-сайт значительно упростит задачу по взлому вашего приложения.

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

Как?​

Если в вашем приложении нет необходимости в навигации, вы можете вызвать event.preventDefault() в обработчике события will-navigate. Если вы знаете, на какие страницы может перейти ваше приложение, проверьте URL в обработчике события и разрешайте навигацию только в том случае, если она соответствует ожидаемым URL-адресам.

Рекомендуется использовать парсер URL-адресов Node.js. Простые сравнения строк могут иногда быть обмануты — проверка startsWith('https://example.com') позволит https://example.com.attacker.com пройти.

const URL = require('url').URL

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. Отключить или ограничить создание новых окон​

Если у вас есть известный набор окон, рекомендуется ограничить создание дополнительных окон в вашем приложении.

Почему?​

Подобно навигации, создание новых webContents является распространенным вектором атак. Злоумышленники пытаются убедить ваше приложение создать новые окна, фреймы или другие процессы рендеринга с большими привилегиями, чем у них было раньше; или со страницами, которые они раньше не могли открыть.

Если вам нет необходимости создавать окна помимо тех, которые вы знаете, что вам нужно создать, отключение создания дает вам немного дополнительной безопасности без затрат. Это часто характерно для приложений, которые открывают одно BrowserWindow и не нуждаются в открытии произвольного количества дополнительных окон во время выполнения.

Как?​

webContents будет делегировать своему обработчику открытия окон обработчику открытия окон перед созданием новых окон. Обработчик получит, среди прочих параметров, url , которое запрашивалось для открытия окна, и опции, используемые для его создания. Рекомендуется зарегистрировать обработчик для мониторинга создания окон и отклонять все неожиданные запросы на создание окон.

const { 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. Не используйте shell.openExternal с недоверенным содержимым​

API модуля shell openExternal позволяет открыть заданный URI протокола с помощью встроенных утилит системы. Например, на macOS эта функция аналогична утилите командной строки open и откроет соответствующее приложение на основе URI и ассоциации с типом файла.

Почему?​

Неправильное использование openExternal может быть использовано для компрометации системы пользователя. При использовании openExternal с недоверенным содержимым это может привести к выполнению произвольных команд.

Как?​

//  Bad
const { shell } = require('electron')
shell.openExternal(USER_CONTROLLED_DATA_HERE)

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

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

Следует стремиться использовать последнюю доступную версию Electron. При выпуске новой основной версии необходимо как можно быстрее обновить приложение.

Почему?​

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

И Chromium, и Node.js – это впечатляющие инженерные решения, созданные тысячами талантливых разработчиков. Благодаря их популярности, их безопасность тщательно проверяется и анализируется столь же опытными исследователями безопасности. Многие из этих исследователей ответственно раскрывают уязвимости, что, как правило, означает, что исследователи дают Chromium и Node.js некоторое время на исправление проблем перед публикацией. Ваше приложение будет более безопасным, если оно использует последнюю версию Electron (и, следовательно, Chromium и Node.js), для которых потенциальные проблемы безопасности не так широко известны.

Как?​

Переходите к приложению на одну основную версию за раз, обращаясь к документу Electron о изменениях в работе для определения необходимости обновления кода.

17. Проверяйте отправителя всех сообщений IPC​

Всегда проверяйте входящие сообщения IPC по свойству sender , чтобы убедиться, что вы не выполняете действия или не отправляете информацию недоверенным рендерерам.

Почему?​

Все веб-фреймы теоретически могут отправлять сообщения IPC в основной процесс, включая iframe и дочерние окна в некоторых сценариях. Если ваше сообщение IPC возвращает данные пользователя отправителю через event.reply или выполняет привилегированные действия, которые рендер не может выполнить напрямую, убедитесь, что вы не слушаете сообщения от сторонних веб-фреймов.

По умолчанию необходимо проверять отправителя всех сообщений IPC.

Как?​

// 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;
}