electron защита исходного кода
NW.js или Electron?
Если вы хотите создать собственное десктопное приложение на основе веб-технологий, то мир опенсорса предлагает два основных варианта: NW.js (ранее известный как node-webkit) и Electron (atom-shell). Выбор между ними не так очевиден, поэтому я решил создать сравнительную таблицу и остановиться на самых важных отличиях.
И NW.js и Electron предоставляют платформу для разработки десктопных приложений с HTML в качестве представления и NodeJS для доступа к системному API (для работы с жестким диском, железом и т.д.). Но существуют принципиальные различия между двумя проектами.
Парадигма
В NW.js точкой входа в приложение является веб-страница. Вы указываете URL основной страницы в package.json и она открывается как главное окно приложения. В Electron точка входа — это программа на NodeJS. Вместо указания URL-адреса напрямую вы «вручную» создаете окно и загружаете в него HTML-файл с помощью API.
Это чрезмерное упрощение, но можно сказать, что парадигма NW.js более браузера-ориентированная. NW.js загружает указанную HTML-страницу и эта страница получает доступ к контексту Node.js. Если открыто больше одного окна, то все они получают доступ к этому общему Node.js контексту. Это означает, что вы можете получить прозрачный доступ к DOM всех открытых окон.
Electron, с другой стороны, имеет более NodeJS-ориентированный подход. Он запускает среду выполнения Node.js, которая получает возможность открывать окна, в которые вы можете затем загружать веб-страницы. Это означает, что связать несколько окон с основным процессом намного сложнее.
Победитель: зависит от ваших потребностей.
Защита исходного кода
В Electron нет какого-либо механизма для защиты вашего исходного кода. Asar трудно назвать приемлемой защитой, учитывая что это простой tar-архив и фактически любой пользователь может «распаковать» вашу программу как обычный архив и получить доступ ко всем ресурсам и исходному коду.
Как выполнить обфускацию исходного кода и защитить источник в электронном js
Недавно я разработал приложение со структурой electron и теперь беспокоюсь о защите исходного кода после прочтения вопросов безопасности, связанных с электронным кодом JavaScript.
Я имею в виду, что обратный инжиниринг кода возможен, даже если приложение создано для производства. Мое приложение содержит много важной информации, такой как GitHub Private Token для автоматического обновления и многое другое.
Я только что прошел много SO постов, но не нашел идеального ответа, поэтому решил проблему. Обфускация кода javascript или защита исходного кода невозможна с электроном? Однако, Obfuscation не защищает код полностью, но может усложнить реверс-инжиниринг. если есть обходной путь для этого, дайте мне знать. Я не нашел больше, чем tl;dr в электронном посте, связанном с безопасностью.
Я нашел способ запутывания с помощью обфускатора, но, похоже, ему понадобится запутывание вручную и ничего особенного в защите исходного кода, как в <
4 ответа
В противном случае ваши файлы являются скриптами, все эти шаги только замедляют атакующего (Тактика многих защит), но не мешают им получить к ним доступ. DevTools довольно легко открыть, и люди смогут читать код каким-либо образом, в той или иной форме. И если кто-то получит ваш обфусцированный код, просто восстановить то, что происходит (см. Здесь для справки: https : //www.youtube.com/watch? v = y6Uzinz3DRU )
Если вы хотите защитить себя от манипулирования кодом, есть лучшие способы сделать это. Как хеширование, изоляция контекста и т. Д. У электрона есть целая глава по этому вопросу.
Существует библиотека под названием bytenode, которая позволяет вам конвертировать ваши файлы Javascript в двоичные файлы, чтобы никто не мог их прочитать.
Сначала установите bytenode на свой сервер и в свою папку:
Создайте обычный файл nodeJS со следующим кодом. Давайте представим, что мы называем следующий код: ok.js
Затем в основном JS-файле вы вызовете свой двоичный файл, назовем его test.js:
Затем вы будете вызывать test.js: узел test.js для его проверки. Сделайте «cat ok.jsc», чтобы увидеть, что это действительно двоичный файл и никто не может увидеть ваш код. Вы можете переместить исходный файл js простого теста в другое место.
Если вы имеете в виду код, который вы по какой-то причине должны иметь на стороне клиента, то запутывание может определенно помочь. Нет такой вещи как запутывание, которое невозможно победить; тем не менее, это может поднять стоимость обфускации до такой степени, что злоумышленникам это просто не стоит.
OWASP Mobile Top 10 2016-M9-Reverse Engineering упоминает это: «Чтобы предотвратить эффективный обратный инжиниринг, вы должны использовать инструмент для запутывания». Тогда вы также можете воспользоваться самозащитой во время выполнения, которую вы также можете найти на OWASP list: «Мобильное приложение должно быть в состоянии обнаружить во время выполнения, что код был добавлен или изменен из того, что он знает о своей целостности во время компиляции. Приложение должно быть в состоянии должным образом реагировать во время выполнения на целостность кода нарушение».
При сравнении различных обфускаторов важно проверить, предоставляют ли они поддержку и документацию, и убедиться, что компания, стоящая за ними, не будет добавлять вредоносные программы и скрывать их в запутанном коде. Вот где бесплатные обфускаторы часто заканчиваются.
Проверьте Jscrambler для корпоративного решения. Они поддерживают Electron, и полный список их преобразований обфускации можно найти здесь.
Производительность web-страницы и Electron/NW.js
Как я понимаю Electron/NW.js по сути просто открывает окно браузера с нужным контентом, но если взять web-страницу и открыть её в Chrome и ту же саму страницу запихнуть её в Electron/NW.js будет ли отличатся производительность?
Под производительностью я понимаю как CSS анимации, так и скорость выполнения JS. (Время загрузки страницы не особо интересует)
Примеры задач:
Буду рад как и домыслам так и обоснованным ответам.
2 ответа 2
В теории, производительность Electron и NW.js должны быть сравнимыми с соответствующими десктопными версиями Chrome/Chromium. Я тесты не делал, но не заметил особых отличий в русурсоёмких частях приложения, над которым работал.
В NW.js версий до 0.22 была проблема с значительным падением производительности, если использовалась компиляция в V8 Snapshot, которая позволяет защитить код приложения от декомпиляции. Начиная с версии 0.22 эту проблему исправили.
Насколько я знаю в плане производительности Electron быстрее (буквально на несколько миллисекунд приложение запускается и отвечает на запросы извне быстрее).
Сравнение движков в плане разработки:
Защита исходного кода
В Electron нет какого-либо механизма для защиты вашего исходного кода. Asar трудно назвать приемлемой защитой, учитывая что это простой tar-архив и фактически любой пользователь может «распаковать» вашу программу как обычный архив и получить доступ ко всем ресурсам и исходному коду.
До свидания, Electron. Здравствуйте, настольные PWA
Автор материала, говорит, что он, возможно, слишком торопится, но то, о чём он хочет рассказать, представляет собой, по меньшей мере, весьма интересную новость. Речь идёт о настольных прогрессивных веб-приложениях, которые вполне могут значительно потеснить позиции приложений, основанных на Electron.
Новшества Chrome v70
Свежая версия Chrome (v70) поддерживает настольные прогрессивные веб-приложения (Desktop Progressive Web Apps, PWA) на платформах Linux и Windows.
Если взглянуть на список поддерживаемых систем, тут же становится заметным отсутствие в нём MacOS. Однако это так лишь до тех пор, пока не выйдет Chrome v72.
Важно отметить, что хотя эта возможность в MacOS по умолчанию не включена, её можно активировать с помощью соответствующего флага. Для этого надо открыть Chrome, перейти по адресу chrome://flags и найти там этот флаг. Можно и перейти к флагу напрямую, воспользовавшись ссылкой chrome://flags/#enable-desktop-pwas.
Что такое прогрессивные веб-приложения?
В особые подробности, касающиеся PWA, мы тут вдаваться не будем. Вот раздел документации Google, в котором можно почитать о них. Для того чтобы своими глазами увидеть PWA и попробовать их в деле, откройте Chrome для Android или Safari в iOS (тут, правда, поддерживаются не все возможности PWA) и посмотрите эти примеры. А вот — выступление на эту тему с Google I/O ‘18.
Что такое Electron?
Electron — это платформа, которая позволяет разработчикам создавать кросс-платформенные настольные приложения с использованием JavaScript, HTML и CSS. Здесь же используются некоторые замечательные JavaScript-библиотеки и фреймворки. Это облегчает веб-программистам вхождение в разработку настольных приложений. Приложения, основанные на Electron, в последние годы приобрели огромную популярность. В рамках таких проектов, как Slack, VS Code, Atom, Discord, вложены немалые силы в разработку приложений с использованием Electron. Если вам эти проекты не знакомы, то вам, определённо, стоит взглянуть на соответствующие приложения и сервисы. Традиционные настольные приложения нередко казались какими-то неуклюжими, элементы их интерфейсов выглядели как нечто устаревшее. Electron, определённо, принёс красоту и изящество в мир настольных приложений.
При чём тут PWA?
Хотя Electron-приложения — это растущее и развивающееся явление, и их реализация близка к реализации веб-приложений, у них, всё же, есть некоторые минусы. Во-первых, такие приложения используют собственные экземпляры браузера Chromium. Многие знают о том, сколько оперативной памяти нужно для работы Chrome. Теперь, для того, чтобы оценить ситуацию, возникающую в системе при одновременном запуске нескольких Electron-приложений, надо взять их количество и умножить на этот объём памяти. Если интересно — откройте несколько Electron-приложений и посмотрите на то, сколько памяти они потребляют.
Чрезмерное использование памяти — это само по себе не очень хорошо, а сюда ещё надо добавить то, что многие Electron-приложения специфическим образом взаимодействуют с Node.js, не обязательно делая это так же, как соответствующие веб-приложения.
Использование Electron добавляет сложностей, связанных с поддержкой старых версий программ и с наладкой процесса обновления приложений.
Теперь поговорим о настольных PWA. Представьте себе приложения, которые выглядят как те, что написаны на Electron, с которыми так же удобно работать, но при этом устанавливать их проще простого, обновляются они тоже без проблем, в ходе передачи клиенту материалов единственного веб-приложения. Возникает такое ощущение, что Chrome задаёт стандарт для подобного сценария поведения в настольных PWA. Когда пользователь, работающий в Chrome, посещает некую веб-страницу, и представленное ей приложение соответствует этому набору критериев, у разработчика приложения появляется возможность предложить пользователю установить приложение на его компьютер. Приглашение выглядит примерно так, как показано ниже.
После запуска подобного приложения оно открывается в браузерном окне, не оснащённом обычными элементами управления. Такое приложение воспринимается как настоящее настольное приложение.
Пример PWA
Вот пример настольного PWA, скриншоты которого были использованы выше в виде иллюстраций. Вотего репозиторий на GitHub. Для того чтобы установить это приложение, нужно включить соответствующий флаг в Chrome и провести на сайте хотя бы 30 секунд.
Как уже было сказано, веб-приложение, для того, чтобы считаться настольным PWA, должно соответствовать определённому набору требований. Если вы хотите создать и испытать собственное настольное PWA, можете взять за основу этот репозиторий и учесть требования. Если сделать краткую сводку по ним, то получится следующее:
Дополнительные примеры
Если вы работаете на MacOS, то PWA могут счесть, что установить их вы не сможете, и не покажут вам приглашение для их установки. Если включить соответствующие флаги и повозиться с консолью разработчика, можно добиться от PWA того, что они приглашение на установку выведут. Вот некоторые из существующих PWA, которые удалось установить на Mac.
Starbucks
Компания Starbucks вложила немало сил в разработку отличного PWA. Их настольное приложение получилось прямо-таки впечатляющим.
Google Maps
Это — просто замечательное приложение. Оно делает своё дело и не особенно сильно нагружает систему, отличаясь быстрой работой и отзывчивым дизайном. Для установки этого приложения нужно исхитриться и загрузить мобильный сайт Google Maps.
Компания Twitter постаралась при разработке мобильного PWA, а настольную версию можно считать достойным дополнением к мобильному приложению.
Итоги
Не смотря на то, что вокруг настольных PWA поднято много шума, нужно отдавать себе отчёт в том, что эта технология пока находится на стадии становления. В частности, можно отметить следующие направления развития настольных PWA:
После того, как технологии разработки настольных PWA достаточно разовьются, эти приложения станут серьёзными конкурентами сегодняшних проектов, основанных на Electron.
Документация Electron
Docs / Guides / Безопасность, нативные возможности и ваша ответственность v15.0.0
Безопасность, нативные возможности и ваша ответственность
Как веб-разработчики, мы заботимся о безопасности браузера и риски, связанные с кодом, который мы пишем, достаточно небольшие. Наши веб-сайты имеют ограниченные полномочия в песочнице, и мы верим, что пользователи довольны браузером, созданным большой командой инженеров, которая может быстро реагировать на последние обнаруженные угрозы безопасности.
Когда вы работаете в среде Электрон, важно понимать, что это не веб браузер. Электрон позволяет создавать функционально развитые приложения для настольных компьютеров с помощью веб технологий, но ваш код обладает большими возможностями. JavaScript имеет доступ к файловой системе, пользовательским скриптам и т. д. Благодаря этим возможностям вы можете создавать высококачественные нативные приложения, но это так же множит риски увеличивающиеся с дополнительными полномочиями вашего кода.
Учтите что показ произвольного содержимого от недоверенных источников влечет за собой риски безопасности, которые Электрон не предназначен купировать. К сведению, наиболее популярные приложения Электрон (Atom, Slack, Visual Studio Code, etc) предназначены для локальной работы (или с доверенными удаленными узлами, без Node интеграции). Если ваше приложение выполняет код из онлайн источника, вы обязаны обеспечить безопасность кода.
Отчеты по безопасности
Для получения информации о том, как правильно устранять уязвимости Electron, загляни в SECURITY.md
Вопросы и обновления безопасности Chromium
Electron keeps up to date with alternating Chromium releases. For more information, see the Electron Release Cadence blog post.
Важно помнить, что безопасность вашего Electron приложения является результатом общей безопасности основы платформы (Chromium, Node.js), самого Electron, всех NPM-зависимостей и вашего кода. Поэтому вы обязаны следовать нескольким важным рекомендациям:
Keep your application up-to-date with the latest Electron framework release. When releasing your product, you’re also shipping a bundle composed of Electron, Chromium shared library and Node.js. Vulnerabilities affecting these components may impact the security of your application. By updating Electron to the latest version, you ensure that critical vulnerabilities (such as nodeIntegration bypasses) are already patched and cannot be exploited in your application. 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.
Изоляция ненадежного контента
Предупреждение безопасности Electron
Чеклист: рекомендации по безопасности
You should at least follow these steps to improve the security of your application:
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 имеет 3 главных преимущества:
1) It authenticates the remote server, ensuring your app connects to the correct host instead of an impersonator. 2) It ensures data integrity, asserting that the data was not modified while in transit between your application and the host. 3) Он шифрует трафик между вашим пользователем и хостом назначения, что усложняет перехват информации, отправленную между вашим приложением и хостом.
2) Do not enable Node.js Integration for Remote Content
This recommendation is the default behavior in Electron since 5.0.0.
Почему?
При отключении интеграции с 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.
In the following example preload script, the later loaded website will have access to a window.readConfig() method, but no Node.js features.
3) Включите контекстную изоляцию для удаленного содержимого
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.
Why & How?
For more information on what contextIsolation is and how to enable it please see our dedicated Context Isolation document.
4) Enable 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.
When creating a window, pass the sandbox: true option in webPreferences :
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.
6) Do Not Disable WebSecurity
Recommendation is Electron’s default
Do not disable webSecurity in production applications.
Почему?
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.
CSP HTTP Header
Electron respects the Content-Security-Policy HTTP header which can be set using Electron’s webRequest.onHeadersReceived handler:
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, such as using the file:// protocol, to set a policy on a page directly in the markup using a tag:
8) Do Not Set allowRunningInsecureContent to true
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.
9) Do Not Enable Experimental Features
Recommendation is Electron’s default
Advanced users of Electron can enable experimental Chromium features using the experimentalFeatures property.
Почему?
Experimental features are, as the name suggests, experimental and have not been enabled for all Chromium users. 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.
10) Do Not Use enableBlinkFeatures
Recommendation is Electron’s 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.
11) Do Not Use allowpopups
Recommendation is Electron’s default
Почему?
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.
12) Verify WebView Options Before Creation
It is a good idea to control the creation of new tags from the main process and to verify that their webPreferences do not disable security features.
Почему?
Since live in the DOM, they can be created by a script running on your website even if Node.js integration is otherwise disabled.
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
13) Disable or limit navigation
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.
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.
15) Do not use openExternal with untrusted content
Shell’s openExternal 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.
16) Use a current version of 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.
Copyright OpenJS Foundation and Electron contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.