#node.js #security #eval
#node.js #Безопасность #eval
Вопрос:
Есть ли какой-нибудь способ предотвратить использование eval и друзей в коде nodejs? Он использовался по крайней мере несколькими вредоносными пакетами npm, и у меня нет причин использовать его в моем текущем проекте.
Тот факт, что существует объявление CSP с небезопасной оценкой, подразумевает, что это должно быть возможно на уровне V8, но, насколько я могу судить, node не предоставляет эту функциональность. (если бы у меня был свой путь, запрет eval был бы по умолчанию …) Я знаю, что существует правило eslint без оценки, что является хорошим началом, но я ищу что-то с гарантиями времени выполнения, которое также включает node_modules .
Комментарии:
1. Какую программу вы пишете? Может быть, покажите нам какой-нибудь код.
2. Это всего лишь базовое экспресс-приложение, ничего особенного, хотя мы стараемся максимально заботиться о безопасности из-за нашего сегмента рынка, и большинство атак начинаются с выполнения произвольного кода. Как отображение кода поможет ответить на вопрос? Это довольно общий термин. Я просто хочу убедиться, что что-то подобное
eval("console.log('hello world')")не сработает.3. Вы не можете изменить, как Node.js интерпретируйте код.
4. Вы бы сказали, что ваш вопрос не обязательно касается предотвращения загрузки через
eval(), но в первую очередь для обнаружения использованияeval()в ваших проектах и их зависимостях?5. @esqew Конечно, если он включает зависимости.
Ответ №1:
Вы не можете изменить, как Node.js интерпретируйте код, если вы сами не напишете / не измените интерпретатор. Вы можете использовать линтеры, такие как ESLint, с правилом no-eval, чтобы убедиться, что в вашем коде их нет, если это не требуется.
eval само по себе это не является злом. Это действительно служит некоторым законным целям.
Это небезопасно только тогда, когда вы используете его небезопасным образом.
Это как кухонный нож. Он безопасен, когда вы используете его правильно и используете для того, для чего он предназначен. Если вы попытаетесь поковырять им в зубах, то сможете. Но это, вероятно, не очень хорошая идея.
То, что вы спрашиваете сейчас, похоже на вопрос, как вы можете не позволить ножу быть острым, потому что он потенциально может порезать вас.
Есть и другие, более важные вещи, о которых стоит беспокоиться.
- Безопасен ли ваш сервер без неправильной настройки?
- Вы действительно установили правильные пакеты, а не какие-то вредоносные с похожими именами, ожидающие, что вы сделаете опечатку?
- Вы проверяли содержимое пакета перед запуском
npm i? - Вы случайно передали конфиденциальную информацию в систему управления версиями?
- Защищена ли ваша база данных? Он случайно настроен на подключение к Интернету, хотя этого не должно быть?
Просто назову некоторые из них. Есть сотни, возможно, тысячи других моментов, о которых вам следует беспокоиться с точки зрения общей безопасности вашей системы.
Примечание: За 0-дневные уязвимости вы можете только молиться.
Комментарии:
1. Да, у eval действительно есть пара полезных целей. Не так много, но они есть. Однако мы им не пользуемся. Позвольте мне спросить вас вот о чем: если у вас есть острый кухонный нож, которым вы не пользуетесь, кладете ли вы его обратно в ящик или ждете, пока кто-нибудь собьет его со стола и наступит вам на ногу?
2. Что касается 1-5, я знаю обо всех этих вещах, и я достаточно уверен во всех этих вещах, но они не могут быть достаточно повторены. Хотя это не спасет меня, возможно, это спасет кого-то еще, кто читает этот пост.
3. Для записи, я не был тем, кто отклонил этот ответ.
4. Ну, ownvoting — это то, что сделало StackOverflow, StackOverflow. Но позвольте мне повторить это: вы не можете изменить способ Node.js интерпретируйте код, если вы сами не напишете / не измените интерпретатор. (Кухонный нож, вероятно, недостаточно хороший пример. Я думаю, что урановые руды будут лучшей аналогией)