Как для Node.js защитить process.env от чтения сторонними npm-пакетами?

Question

[monochromer]

Очень часто всякие настройки, например, подключение к базам данных, передаются как переменные окружения. Но любой сторонний скрипт может прочитать process.env. Как защититься от этого?

Comments

[Aves]

Где защититься? В bash можно сделать alias node="env -i node"

[monochromer]

Aves, предположим в зависимости проекта попал зловредный скрипт evil.js.
Приложение стартует с передачей переменных окружения:

DB_URI="mongodb://user:pass@host:port/dbname" node app.js

Cторонний скрипт может прочитать эти переменные и отправить себе:
const env = JSON.stringify(process.env);
Хочется придумать способ не давать читать такие данные кому попало.

[Aves]

monochromer,

const {DB_URI} = process.env;
delete process.env.DB_URI;

Но особого смысла прятать process.env нет, скрипт может спокойно сделать например fs.readFileSync(`/proc/${process.pid}/environ`)

[Alex Wells]

monochromer, в добавок к ответу Aves - используйте доверенные пакеты, а у недоверенных проверяйте исходники и форкайте.

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

[monochromer]

Alex Wells, а если у проекта 10 зависимостей, каждая их которых имеет 10 зависимостей, каждая из которых..., как проверить все эти исходники? Что если npm audit не поможет?

[Alex Wells]

monochromer, тогда читайте второй параграф)

[monochromer]

Alex Wells, Что значит "база должна иметь доступ с определенных айпи"? Грубо говоря, есть два сервера - на одном работает node-приложение, на другом - сервер базы данных и все, тут не супер-энтерпрайз. Node-приложение должно иметь доступ на все операции с данными. А как ограничивают действия?

[sim3x]

monochromer,

предположим в зависимости проекта попал зловредный скрипт evil.js.

тогда гайки.

Можно заморочиться selinux, но сложно и его возможности не безграничны

[Андрей]

monochromer, ну, у серверов статический ip, СУБД обычно поддерживают указание для пользователя его ip. Если правильный пользователь с правильным паролем входит с левого ip =401

[monochromer]

Андрей, у настоящих серверов - да, а если используются PaaS или SaaS?

[Андрей]

monochromer, у клиента должен быть белый статический апи, да.

[Alex Wells]

monochromer, ну, собственно это и не есть супер-энтерпрайз. Любая SQL база так может, а монгой вообще нехрен себе забивать голову, имхо)) Но почему-то подозреваю, что и она тоже так может.

А на счет сервера с нодой - ну он же скорее всего и держит веб-сервер, а значит ему нужен статический айпи

[jeruthadam]

Alex Wells,

используйте доверенные пакеты, а у недоверенных проверяйте исходники и форкайте

Хорошая шутка. У меня во вью стартере 1600+ зависимостей. Проверять все предлагаете?

[Alex Wells]

jeruthadam, ну, предположение в том, что "доверенные" пакеты должны сами проверять пакеты, которые они используют, но да, другого выбора особо то и нет)

[chupasaurus]

jeruthadam, да.

[jeruthadam]

chupasaurus, что "да"? Ты сам проверяешь 1600+ пакетов?

[chupasaurus]

jeruthadam, да. А ещё после этого держу своё зеркало и проверяю изменения.

[jeruthadam]

chupasaurus, и каким образом происходит проверка 1600+ пакетов? Есть инструменты, кроме сторонних сервисов?

[Валентин]

предположим в зависимости проекта попал зловредный скрипт evil.js

Свой прокси-репозиторий внешних пакетов + приватный репо для своего кода. Жестко фиксировать версии. Хранить package.lock в репозитории. Эти действия уже заметно уменьшают вероятность такого сценария. Ну и плюс серверы репозиториев умеют сканировать свои пакеты на наличие известных уязвимостей.
Ну и в контейнере свой код запускать, за основу контейнера опять же брать свой образ, а не какой-нить публичный ubuntu, и все это в приватном docker registry хранить.

Answer 1

[Андрей]

Запускать приложение под него созданным пользователем, сделав файл конфига доступным только этому пользователю.

Comments

[monochromer]

npm-модуль же запускается не отдельно, а как часть приложения доверенного пользователя.

Answer 2

[ofigenn]

В начале index.js (до первого require) скопировать process.env и заменить его пустым объектом)

Comments

[monochromer]

Заменять весь process.env явно не стоит

[jeruthadam]

monochromer, а dotenv не защищает от этого всего? Если нет - то зачем он нужен?

[monochromer]

jeruthadam, нет, не защищает. Он просто позволяет вместо ручного задания переменных в консоли занести их в файл. Обычно его используют, когда число переменных превышает 3-4 и есть большое число конфигураций - development, test, staging, production.

[ofigenn]

monochromer, почему не стоит? Страшно?)

[monochromer]

ofigenn,потому что в process.env много другой системной информации, которая может использоваться самим node.js.

[ofigenn]

Ну, так оставь там то, что не хочешь защищать. Да, и очень хотелось бы знать, что же там такое важное для ноды, кроме NODE_ENV?)

[monochromer]

Ну, так оставь там то, что не хочешь защищать.

собственно, к этому пока и пришли в обсуждениях пару дней назад

Да, и очень хотелось бы знать, что же там такое важное для ноды, кроме NODE_ENV?)

И что же останавливает?

[ofigenn]

Меня ничего не останавливает) Был рад помочь) Не благодари)

Answer 3

[Алексей Ступеньков]

Не передавать данные через environment

Comments

[monochromer]

Алексей Ступеньков, а как Вы передаете данные

Answer 4

[index0h]

В полной мере - никак