exec 和 eval 在生产环境等于“开后门”，因它们直接执行字符串代码，绕过语法检查与作用域约束，极易导致远程代码执行；真实漏洞常藏于日志模板、配置解析等场景，危险性高且性能差。
为什么 exec 和 eval 在生产环境基本等于“开后门”
因为它们会把字符串当作 Python 代码直接执行，绕过所有语法检查、作用域约束和静态分析。哪怕只传入一个用户可控的字段（比如 URL 参数、表单输入），攻击者就能执行任意代码——删库、读文件、反弹 shell 都是分分钟的事。
常见错误现象：eval("os.system('rm -rf /')") 看似荒谬，但真实漏洞往往藏在更隐蔽的地方，比如拼接日志模板、动态配置解析、低代码表达式引擎里。
- 使用场景：几乎全是“想省事”的地方——做简易计算器、临时调试、配置项动态求值、规则引擎 PoC
- 参数差异：
eval只能执行表达式（返回值），exec能执行语句（定义函数、import、赋值），危险性更高 - 性能影响：每次调用都要触发 Python 解析器，比普通函数调用慢 10–100 倍，且无法被 JIT 或缓存优化
替代 eval 的安全方案：从 ast.literal_eval 到白名单字典
ast.literal_eval 是唯一被官方推荐用于“可信字符串转结构”的函数，它只允许 list、dict、str、int、float、bool、None 这几种字面量，连元组都不行（(1,2) 会报 ValueError）。
但如果业务真需要“计算”，比如规则引擎里的 "age > 18 and status == 'active'"，就得自己写白名单解析器，而不是放任 eval。
立即学习“Python免费学习笔记（深入）”；
- 不要用
json.loads()替代ast.literal_eval()：JSON 不支持单引号、True/False小写、注释，容易因格式错报错 - 别试图用正则“过滤危险关键词”：
re.sub(r'(os|subprocess|__)', '', s)完全无效，绕过方式太多（getattr(__import__('os'), 'system')） - 真正安全的做法是：把可计算字段、操作符、常量全部硬编码进白名单字典，再用
operator模块执行，例如operator.gt(user.age, 18)
禁用 exec 的落地手段：从 CI 检查到运行时拦截
光靠开发自觉没用。必须让 exec（以及 compile + exec 组合）在代码提交或启动阶段就失败。
CI 层面最简单有效的是用 grep 或 pygrep 扫描：
grep -r "exec(" --include="*.py" . | grep -v "test_"
更进一步，可以用 ast 模块写个检查脚本，识别所有 exec 调用点并打印上下文行号。
- 运行时拦截：在应用启动时重置内置函数，
builtins.exec = lambda *a, **kw: _raise(RuntimeError("exec disabled"))，但注意某些库（如 IPython、Jinja2）内部会用，得排除路径 - 别漏掉等价写法：
exec(compile(...))、eval(compile(...), ..., ...)、getattr(builtins, 'exec')都得一并封禁 - Docker 镜像构建时加
sed -i '/exec(/d' *.py是自欺欺人，改源码不如改流程
当真绕不开动态执行时：沙箱不是万能的，隔离才是底线
如果业务强依赖动态代码（如插件系统、在线编程题库），别碰 exec，直接上进程级隔离。
用 subprocess.run 启一个最小权限子进程，限定 CPU/内存/超时，并通过 stdin/stdout 通信。Python 自带的 RestrictedPython 库早已停止维护，而 pysandbox 类项目实际防护能力极弱，还拖慢性能。
- 别信“禁用
__import__就安全”：攻击者可用importlib.import_module、getattr(sys.modules, '__builtin__')绕过 - 别在容器里跑不受信代码还挂载宿主目录：即使用了
seccomp，内核漏洞和 side channel 依然存在风险 - 最简隔离方案：每个用户代码用独立
docker run --rm --memory=64m --cpus=0.1 --network=none执行，输出仅限 JSON
复杂点在于通信协议设计和超时处理，而不是怎么让 exec 更“安全”。只要代码来源不可控，执行本身就必须跨进程、跨用户、跨命名空间。
