node js защита исходного кода
Я хочу использовать node.js в моем следующем проекте, но моему боссу не нравится, что наши конкуренты могут читать исходный код.
Есть ли способ защитить код JavaScript?
13 ответов
Вы можете сделать это с помощью NativeExtension для узла
YourCode.jse будет зашифрованной версией вашего исходного кода (ключ для расшифровки не будет нигде в текстовом виде, потому что процесс расшифровки происходит в собственном расширении).
Просто включите лицензионное соглашение и дайте им исходный код. Они могли бы хотеть настроить это так или иначе.
Упакуйте свою основную логику в модули. Эти модули можно собрать, а затем запустить через закрытие Google. Вы даже можете сделать это как задание Grunt как часть процесса сборки.
Если вы хотите использовать Javascript и Node.js для предоставления защищенного «продукта» (который в этом контексте является приложением или услугой, требующей установки на сервере, который не контролируется вашей компанией), вы не можете защитить его либо как единственный доступный вариант для Вы (обфускация) не обеспечивает такой защиты.
Следует отметить, что даже если ваш продукт предоставляется в виде двоичного исполняемого файла, это не гарантирует, что вы сможете защитить интеллектуальную собственность, которую он содержит, поскольку любой двоичный файл может быть декомпилирован в понятный формат. В этом случае мы получаем некоторый уровень безопасности, основанный на чрезмерных ресурсах (время / опыт), необходимых для преобразования низкоуровневого машинного кода (как предусмотрено декомпиляцией) в логические конструкции более высокого уровня, используемые современными языками программирования. (Это от того, кто однажды декомпилировал CP / M в понимание его внутреннего дизайна вручную.;)
Вы не можете быть абсолютно уверены, что никто не сможет прочитать ваш код. Вы можете использовать обфускацию или минификацию, что может значительно усложнить декодирование вашего кода. Одним из примеров обфускатора / миниатора является компилятор закрытия Google для JavaScript.
Прочтите статью, и вы увидите, что «по-настоящему» «компилировать код Node.js (JavaScript) в байт-код V8. Это позволяет вам скрыть или защитить исходный код лучше, чем запутывание или другие неэффективные приемы (например, шифрование кода с использованием секретного ключа, который будет встроен в двоичные файлы вашего приложения, поэтому я сказал «по-настоящему»). над).
Проверьте bytenode репозиторий на Github.
Таким образом, я создал законченное решение, которое обрабатывает слияние файлов, увеличение. У вас есть возможность пропустить указанные файлы / папки, а также от слияния. Эти файлы затем копируются в новое выходное местоположение объединенного файла, и ссылки на них перезаписываются автоматически.
PS: Я был бы рад, если бы люди помогли сделать это еще лучше. Это война между ворами и трудолюбивыми программистами, такими как ты. Давайте объединим наши силы, усилим боль в обратном инжиниринге!
Кто-нибудь пробовал nexe или pkg?
Это похоже на хороший вариант. Утилита командной строки, которая компилирует ваше приложение Node.js в один исполняемый файл.
У меня есть мысль. Защитите приложение cpp или java вместо js.
Так что это очень похоже на черный ящик, клиенты ничего не могут сделать с вашим кодом.
Серверный код JavaScript полностью закрыт. Никто не может прочитать это.
Клиентский JavaScript-код полностью с открытым исходным кодом. Каждый может прочитать это.
Для последнего вы ничего не можете сделать, но то же самое относится к RoR, ASP.NET, PHP и т. Д.
Фактический код сервера закрыт, если вы не сделаете его общедоступным.
Если вы делаете библиотеку и пытаетесь продать ее как сторонний источник, тогда она открыта и может быть украдена. Конечно, вы можете подать в суд на них за нарушение авторских прав.
Большинство коммерческих проектов, основанных на узле, являются сервисами.
JXcore (node.js 0.11.X distro) имеет собственную функцию упаковки JX, которая защищает исходный код и ресурсы. Вы даже можете выбрать, будет ли этот конкретный пакет использоваться из других приложений или нет. (автономная ИЛИ библиотека)
Допустим, у вас есть много файлов JS и т. Д., И точка входа в ваш модуль выглядит примерно так;
Если вы просто вызовите метод ниже и скомпилируете его в пакет JX, исходный код будет в безопасности.
Это (скрытие метода) потребуется только для входного файла, поскольку все остальные вспомогательные JS-файлы недоступны из вызывающего приложения.
Вам нужен JXcore для запуска пакетов JX.
Дополнительную информацию можно получить на JXcore
Защита исходного кода от модификации?
Есть ли возможность максимально усложнить (понятно, что на 100% приложение не защитить) получение исходного кода и его модификации для Node.js приложений? На счет обфускации я в курсе, но может есть способы понадежнее?
UPD: самая лучшая защита это какие-нибудь проверки или подгрузка контента по сети.
Есть ли возможность максимально усложнить (понятно, что на 100% приложение не защитить) получение исходного кода и его модификации
Цель подхода состоит в том, чтобы затраченные ресурсы на «кряк» такого приложения превышали затраченные ресурсы на разработку аналога.
UPD: самая лучшая защита это какие-нибудь проверки или подгрузка контента по сети.
Где-то в сторонке тихонько захихикали IDA Pro + Hex-Rays и Wireshark
Где-то в сторонке тихонько захихикали IDA Pro + Hex-Rays и Wireshark
Так никто из комментаторов ничего в пользу защиты и не написал.
P. S. Посмотрел твой GitHub, все стало понятно.
mov eax, 0x80,
> нечего ответить.
> Напиши что посмотрел github профиль и тебе стало все понятно.
Порой хватает просто взглянуть на поделку и она уже взломана)
Комбинируя эти механизмы можно получить неплохой результат.
Так как инструмент пока не в открытом доступе (еще не все сделано, что хотел), я могу на безвозмездной основе предложить автору (ну или другим желающим) помочь сделать относительно защищенный билд приложения.
(контакты для связи в профиле).
Лучшие практические методы для рабочей среды: Защита¶
Обзор¶
Термин «рабочий режим» означает тот этап жизненного цикла программного обеспечения, на котором приложение или API является в целом доступным для конечных пользователей или потребителей. Напротив, на этапе «разработки» происходит активное создание и тестирование кода, и приложение не является открытым для внешнего доступа. Соответствующие системные среды называются, соответственно, рабочей средой и средой разработки.
Настройки среды разработки и рабочей среды при установке, как правило, являются различными, и к этим средам предъявляются абсолютно разные требования. То, что идеально для разработки, не всегда приемлемо в рабочем режиме. Например, в среде разработки можно задать подробное протоколирование ошибок для отладки, тогда как в рабочей среде такая особенность настройки может привести к уязвимости защиты. Во время разработки можно не беспокоиться о масштабируемости, надежности и производительности, тогда как в рабочем режиме все эти вопросы играют решающую роль.
В настоящей статье речь пойдет о лучших практических методах в области защиты приложений Express, развернутых в рабочей среде.
Не используйте устаревшие или уязвимые версии Express¶
Версии Express 2.x и 3.x больше не поддерживаются. Проблемы, связанные с защитой и производительностью в этих версиях, не будут подлежать решению. Не используйте эти версии!
Использование TLS¶
Если ваше приложение предназначено для работы с чувствительными данными или для их передачи, для защиты соединения и данных необходимо использовать криптографический протокол Transport Layer Security (TLS). Данная технология позволяет шифровать данные до передачи с клиента на сервер, тем самым обеспечивая защиту от многих распространенных (и простых) способов несанкционированного доступа. Хотя запросы Ajax и POST могут казаться неочевидными и «скрытыми» в браузерах, инициируемая ими передача данных в сети является уязвимой для незаконного сбора и анализа пакетов и атак посредника (атак «человек посередине»).
Возможно, вам знаком криптографический протокол Secure Socket Layer (SSL). SSL является предшественником TLS. Другими словами, если раньше вы пользовались SSL, пора переходить к TLS. В целом, для работы с TLS мы рекомендуем использовать сервер Nginx. Подробные инструкции по настройке TLS на Nginx (и на других серверах) можно найти в разделе Рекомендуемые конфигурации серверов (Mozilla Wiki).
Использование Helmet¶
Helmet помогает защитить приложение от некоторых широко известных веб-уязвимостей путем соответствующей настройки заголовков HTTP.
Helmet, по сути, представляет собой набор из девяти более мелких функций промежуточной обработки, обеспечивающих настройку заголовков HTTP, связанную с защитой:
Установите Helmet, как обычный модуль:
Затем используйте его в своем коде:
Как минимум, отключите заголовок X-Powered-By¶
Безопасное использование cookie¶
Для того чтобы файлы cookie не подвергали опасности ваши приложения, не используйте стандартные имена сеансовых cookie и соответствующим образом настройте опции защиты файлов cookie.
Существует два основных сеансовых модуля cookie для промежуточной обработки:
Основное различие между этими двумя модулями состоит в способе сохранения сеансовых данных cookie. Промежуточный обработчик express-session сохраняет данные о сеансе на сервере; в самом файле cookie сохраняется только ИД сеанса, но не данные сеанса. По умолчанию, используется хранилище в оперативной памяти, но данный способ не предназначен для рабочей среды. В рабочей среде необходимо настроить масштабируемое хранилище сеансов; см. список совместимых хранилищ сеансов.
Промежуточный обработчик cookie-session, в отличие от описанного выше, реализует хранение на основе файлов cookie: выполняется полная сериализация сеанса в файл cookie, вместо того, чтобы сохранять только ключ сеанса. Этот способ следует использовать только при условии, что данные сеанса имеют относительно небольшой объем и легко могут быть преобразованы в элементарные значения (а не объекты). Хотя браузеры должны поддерживать не менее 4096 байт на каждый файл cookie, позаботьтесь о том, чтобы не допустить превышения данного ограничения. Размер не должен превышать 4093 байт на каждый домен. Кроме того, помните о том, что данные cookie являются видимыми для клиента, поэтому, если по какой-либо причине их следует защитить или скрыть, остановите свой выбор на модуле express-session как на более подходящем.
Не используйте стандартные имена сеансовых cookie¶
Использование имен сеансовых cookie, предлагаемых по умолчанию, может сделать ваше приложение уязвимым для разного рода атак. В данном случае возникает та же проблема с безопасностью, что и при использовании заголовка X-Powered-By : потенциальный злоумышленник может воспользоваться им для идентификации на сервере и организации целенаправленных атак.
Для того чтобы избежать такой проблемы, используйте обобщенные имена cookie; например, при использовании промежуточного обработчика express-session:
Настройка опций защиты cookie¶
Для обеспечения защиты необходимо настроить следующие опции защиты файлов cookie:
Ниже приведен пример с использованием промежуточного обработчика cookie-session:
Обеспечение защиты зависимостей¶
Для управления зависимостями приложения удобно использовать многофункциональный инструмент npm. Но пакеты, с которыми вы работаете, могут обладать критическими уязвимостями защиты, которые также могут повлиять на ваше приложение. Надежность защиты вашего приложения определяется именно надежностью «самого слабого звена» среди зависимостей.
Для того чтобы обеспечить защиту используемых вами сторонних пакетов, используйте один или оба инструмента: nsp и requireSafe. Эти два инструмента выполняют, в основном, одни и те же функции.
Воспользуйтесь этой командой, чтобы передать файл npm-shrinkwrap.json на проверку в nodesecurity.io:
Воспользуйтесь этой командой, чтобы передать файл package.json на проверку в nodesecurity.io:
Ниже показано, как используется requireSafe для проверки модулей Node:
Дополнительные замечания¶
Ниже приводится несколько дополнительных рекомендаций, взятых из исчерпывающего Контрольного списка требований к защите Node.js. В этой публикации можно найти дополнительную информацию по всем приведенным ниже рекомендациям:
Избегайте прочих известных уязвимостей¶
Шпаргалки по безопасности: Nodejs
Довольно много уже было сказано о популярности NodeJS. Рост количества приложений очевиден – NodeJS довольно прост в освоении, имеет огромное количество библиотек, а также динамично развивающуюся экосистему.
Мы подготовили рекомендации для NodeJS разработчиков, основываясь на OWASP Cheat Sheets, которые помогут вам предусмотреть проблемы с безопасностью при разработке приложений.
Рекомендации к безопасности NodeJS приложений можно разделить на следующие категории:
Безопасность при разработке приложения
Избегайте callback hell
Использование функций обратных вызовов (коллбэков) — одна из самых сильных сторон NodeJS, однако при вложенности коллбэков можно легко забыть обработать ошибку в одной из функций. Один из способов избежать callback hell — использование промисов. Даже если используемый вами модуль не поддерживает работу с промисами, вы всегда можете использовать Promise.promisifyAll(). Но даже используя промисы, стоит обращать внимание на вложенность. Чтобы полностью избежать ошибки callback hell придерживайтесь «плоской» цепочки промисов.
Пример callback hell:
Тот же код, с использованием плоской цепочки промисов:
Ограничивайте размер запроса
Разбор тела запроса может оказаться довольно ресурсоемкой операцией. Если не ограничивать размер запроса, злоумышленники смогут отправлять достаточно большие запросы, способные заполнить все дисковое пространство или исчерпать все ресурсы сервера, но в то же время ограничение размера запроса для всех случаев может быть некорректным, так как существуют запросы, как например загрузка файла. Поэтому рекомендуется устанавливать ограничения для разных типов контента. Например, с помощью фреймфорка express это можно реализовать следующим образом:
Следует заметить, что злоумышленник может изменить тип содержимого запроса и обойти ограничения, поэтому необходимо проверять соответствие содержимого запроса на соответствие типу контента, указанному в заголовке запроса. Если проверка типа содержимого влияет на производительность, то можно проверять только определенные типы или запросы, размер которых превышает определенный размер.
Не блокируйте event loop
Важная составляющая языка — event loop, который как раз и позволяет переключать контекст выполнения, не дожидаясь окончания выполнения операции. Однако существуют блокирующие операции, окончания выполнения которых NodeJS приходится дожидаться, прежде чем продолжить выполнение кода. Например, большинство синхронных методов относятся к блокирующим:
Рекомендуется выполнять подобные операции асинхронно:
При этом не забывайте, что код, стоящий после асинхронного вызова будет выполнен, не дожидаясь окончания выполнения предыдущей операции.
Например, в коде, приведенном ниже, файл удалится до того, как он будет прочтен, что может привести к race condition.
Чтобы избежать этого, можно записать все операции в неблокирующую функцию:
Проверяйте поля ввода
Проверка полей ввода — важная часть безопасности любого приложения. Ошибки проверки могут привести к тому, что ваше приложение станет уязвимым сразу для множества типов атак: sql-инъекции, xss, command injection и другим. Чтобы упростить проверку форм можно воспользоваться пакетами validator, mongo-express-sanitize.
Экранируйте пользовательские данные
Одно из правил, выполнение которого поможет вам защититься от xss атак — экранирование пользовательских данных. Для этого можно воспользоваться библиотекой escape-html или node-esapi.
Кроме того, что это поможет при отладке ошибок, логирование может использоваться для реагирования на инциденты. Подробнее о необходимости логирования вы можете почитать тут. Одни из самых популярных пакетов для логирования в NodeJS — Winston и Bunyan. В примере ниже показано как с помощью Winston выводить логи как в консоль, так и в файл:
Контролируйте цикл событий
Если ваш сервер находится в условиях интенсивного сетевого трафика, пользователи могу испытывать сложности с доступностью вашего сервиса. По сути, это атака типа DoS. В таком случае вы можете отслеживать время отклика и, если оно превышает заданное, отправлять сообщение 503 Server Too Busy. Помочь в этом может модуль toobusy-js.
Пример использования модуля:
Примите меры предосторожности против брут-форса
Опять же на помощь приходят модули. Например, express-brute или express-bouncer. Пример использования:
Использование CAPTCHA является еще одним распространенным механизмом противодействия брут-форсу. Часто используемый модуль, помогающий реализовать CAPTCHA — svg-captcha.
Используйте CSRF токены
Один из самых надежных способов защиты от CSRF атак — использование CSRF токена. Токен должен быть сгенерирован с высокой энтропией, строго проверяться и быть привязанным к сеансу пользователя. Для обеспечения работы CSRF токена можно воспользоваться модулем csurf.
Не забудьте добавить токен в скрытое поле на странице:
Более подробно о CSRF токенах можно прочесть в нашей статье.
Удаляйте ненужные роуты
Веб-приложение не должно содержать страниц, которые не используются пользователями, поскольку это может увеличить поверхность атаки. Поэтому все неиспользуемые API роуты должны быть отключены. Особенно стоит обратить внимание на этот вопрос, если вы используете фреймфорки Sails или Feathers, поскольку они автоматически генерируют API эндпоинты.
Защититесь от HPP (HTTP Parameter Pollution)
По умолчанию express складывает все параметры из запроса в массив. OWASP рекомендует использовать модуль hpp, который игнорирует все значения параметров из req.query и/или req.body и просто выбирает последнее значение среди повторяющихся.
Контролируйте возвращаемые значения
К примеру, в таблице пользователей могут храниться важные данные: пароль, адрес электронной почты, дата рождения и т.д. Поэтому важно возвращать только необходимые данные.
С помощью дескрипторов можно описать поведение свойства для различных операций: writable — можно ли менять значение свойства, enumerable — можно ли использовать свойство в цикле for..in, configurable — можно ли перезаписывать свойство. Рекомендуется обращать внимание на перечисленные свойства, так как при определении свойства объекта все эти атрибуты имеют значение true по умолчанию. Изменить значение свойств можно следующим образом:
Для разграничения доступа к данным с учетом ролей может помочь модуль acl. Например, добавление разрешения выглядит следующим образом:
По умолчанию, в случае неперехваченного исключения NodeJS выведет текущий stack trace и завершит поток выполнения. Однако NodeJS позволяет настроить это поведение. В случае появления неперехваченного исключения генерируется событие uncaughtException, которое можно отловить с помощью объекта process:
Стоит помнить, что при возникновении uncaughtException необходимо очистить все выделенные ресурсы (например, файловые дескрипторы и хэндлеры) перед завершением Z процесса, чтобы избежать возникновения непредвиденных ошибок. Настоятельно не рекомендуется продолжать работу программы в случае возникновения uncaughtException.
Также при отображении сообщений об ошибках пользователю не следует раскрывать подробную информацию об ошибке, такую как stack trace.
Безопасность сервера
Устанавливайте флаги для заголовков при работе с куками
Есть несколько флагов, использование которых поможет защититься от таких атак как xss и csrf: httpOnly, запрещающий доступ к кукам посредством javascript; Secure — позволяет отправку куки только по HTTPS и SameSite, определяющий возможность передачи куки стороннему ресурсу.
Устанавливайте HTTP-заголовки для обеспечения безопасности
Ниже приведены заголовки и примеры их подключения, которые помогут вам защититься от ряда распространённых атак. Установка заголовков выполняется с помощью модуля helmet
• Strict-Transport-Security: HTTP Strict Transport Security (HSTS) сообщает браузеру о том, что приложение может быть доступно только по HTTPS
• X-Frame-Options: определяет, может ли страница использоваться в frame, iframe, embed или object
• X-XSS-Protection: позволяет браузеру прекращать загрузку страницы, если он обнаружил отраженную XSS атаку.
• X-Content-Type-Options: используется для предотвращения атаки с использованием MIME типов
• Content-Security-Policy: позволяет предотвращать такие атаки как XSS и атаки внедрения данных
• Cache-Control и Pragma: для управления кэшированием, особенно этот заголовок может быть полезен для страниц, которые содержат конфиденциальные данные. Однако стоит помнить, что отключение кэширования на всех страницах может сказаться на производительности
• X-Download-Options: заголовок запрещает Inter Explorer исполнять скаченные файлы
• Expect-CT: Certificate Transparency — механизм, созданный, чтобы решить некоторые проблемы с инфраструктурой SSL сертификатов, данный заголовок сообщает браузеру о необходимости дополнительной проверки сертификата в логах CT
• X-Powered-By: необязательный заголовок, который используется, чтобы указать технологию, используемую на сервере. Скрыть данный заголовок можно следующим образом:
Кроме того, можно подменить значение, чтобы скрыть реальную информацию об используемых вами технологиях:
Безопасность платформы
Обновляйте ваши пакеты
Безопасность вашего приложения зависит в том числе и от безопасности используемых вами пакетов, поэтому важно пользоваться последней версией пакета. Чтобы убедиться, что используемый вами пакет не содержит известных уязвимостей можно воспользоваться специальным списком OWASP. Также можно воспользоваться библиотекой, выполняющей проверку пакетов на известные уязвимости Retire.js.
Не используйте небезопасные функции
Существуют функции, от использования которых по возможности рекомендуется отказаться. Среди таких функций — eval(), исполняющая принимаемую в качестве аргумента строку. В сочетании с пользовательским вводом использование этой функции может привести к уязвимости удаленного выполнения кода, так как по схожим причинам использование child_process.exec также является небезопасным, так как функция передает принятые аргументы в bin/sh.
Кроме того, существует ряд модулей, пользоваться которыми стоит с осторожностью. Например, модуль fs для работы с файлами. Если определенным образом сформированный пользовательский ввод подать в функцию, то ваше приложение может стать уязвимым к включению локального файла и directory traversal.
Модуль vm, предоставляющий API для компиляции и запуска кода на виртуальной машинеV8, стоит использовать только в песочнице.
Здесь можно ознакомиться с другими функциями, которые могут сделать ваше приложение небезопасным
Будьте осторожны, используя регулярные выражения
Регулярное выражение может быть написано так, что можно добиться ситуации, когда время работы выражения будет расти экспоненциально, что может привести к отказу в обслуживании. Подобные атаки называются ReDoS. Есть несколько инструментов, позволяющих проверить, является ли безопасным регулярные выражение, одно из таких — vuln-regex-detector.
Периодически запускайте линтеры
Во время разработки тяжело удерживать в голове все рекомендации по обеспечению безопасности, а если речь идет о командной разработке, непросто добиться соблюдения правил всеми членами команды. Для таких целей и существуют инструменты для статического анализа безопасности. Такие инструменты, не выполняя ваш код ищут в нем уязвимости. Кроме того, линтеры позволяют добавлять пользовательские правила поиска мест в коде, которые могут быть уязвимы. Самые часто используемые линтеры — ESLint и JSHint.
Используйте strict mode
Javascript имеет ряд небезопасных и устаревших функций, которые не должны использоваться. Чтобы исключить возможность использования этих функций и предусмотрен strict mode.
Придерживайтесь общих принципов безопасности
В описанных рекомендациях основной упор делается на NodeJS, но не стоит забывать про общие принципы безопасности, которые необходимо соблюдать независимо от используемой платформы.