Риски использования eval() (JavaScript и Python)
- Полное выполнение произвольного кода — если вход не полностью доверенный, атакующий получает RCE (чтение/запись файлов, сокеты, выполнение команд, изменение памяти/переменных).
- Кража данных и обход доступа — доступ к переменным, токенам, cookies, локальным функциям.
- XSS (в браузере) — исполнение вредоносного скрипта в контексте страницы.
- DoS и зависание — бесконечные циклы, тяжёлые вычисления, расход памяти/CPU.
- Нарушение политики безопасности (CSP) — eval/Function часто ломают CSP.
- Сложность анализа и тестирования — код динамически формируется, сложнее провести аудит.
- В JavaScript: уязвимости сериализации/прототип-политика при динамическом создании объектов. В Python: доступ к os, subprocess, inspect, встроенным типам и системным ресурсам.
Когда использование eval может быть допустимо
- Только для полностью доверенных входных данных (внутренние инструменты, REPL, отладка).
- В контролируемых окружениях с надёжной изоляцией (изолированный контейнер/процесс с ограничениями).
- Если альтернатив нет и выполнен полноценный аудит + ограничение окружения/ресурсов.
В общем: редкие, хорошо обоснованные случаи; по возможности избегать.
Безопасные альтернативы для динамического выполнения кода
JavaScript
- Для данных: JSON.parse вместо eval для JSON.
- Для HTML: шаблонизаторы/очистка — Mustache/Handlebars, DOMPurify (если нужно вставлять HTML).
- Для вычислений/выражений: библиотеки-парсеры/интерпретаторы — mathjs, jsep + собственный интерпретатор, expression-eval.
- Для выполнения изолированного кода на сервере Node.js: использовать безопасные песочницы (isolated-vm, SES от Agoric) или запуск в отдельном процессе/контейнере с ограничениями; стандартный vm модуль Node.js не даёт полной безопасности по умолчанию.
- new Function() — такая же угроза, как eval; не использовать для недоверенного ввода.
Python
- Для парсинга литералов: ast.literal_eval — безопасно только для литералов Python (строки, числа, списки, словари и т.п.).
- Если нужно вычислять выражения: библиотеки simpleeval, asteval, numexpr — они дают контролируемую семантику выражений.
- RestrictedPython — фреймворк для выполнения ограниченного Python-кода (нужна осторожная настройка).
- Вместо exec/eval: разбирайте AST (ast.parse), валидируйте/фильтруйте узлы и интерпретируйте только разрешённые операции собственным интерпретатором.
- Для полной изоляции: запускать в отдельном процессе/контейнере/VM с ограничениями (seccomp, cgroups, ulimit), или использовать sandboxing платформы.
Митигирующие меры (если нельзя избежать динамики)
- Всегда считать ввод недоверенным; использовать белые списки токенов/операций.
- Ограничить окружение выполнения (explicit globals/locals); но помнить — удаление "__builtins__" не даёт абсолютной безопасности.
- Запуск в отдельном процессе/контейнере под непривилегированным юзером, с таймаутами и лимитами по памяти/CPU.
- Логи и мониторинг исполнения; тестирование подпольных путей атаки.
- Подписание/верификация динамически подгружаемого кода (плагины) и статический аудит.
Краткий вывод
- По умолчанию — не использовать eval/exec для недоверенного ввода. Предпочитать специализированные парсеры/интерпретаторы или обеспечить ОС‑уровневую изоляцию и строгие ограничения, если динамическое исполнение действительно необходимо.