安全边界在于禁用shell解析：优先用subprocess.run([...], shell=false)，若必须shell=true则严格白名单控制；os.system()拼接用户输入绝对禁止，shlex.quote()不可靠；动态参数须按命令语义白名单校验，非通用过滤。
os.system() 和 subprocess.run() 的安全边界在哪
直接用 os.system() 拼接用户输入，等于把 shell 控制权白送出去。哪怕只加了 shlex.quote()，也挡不住绕过技巧（比如用 $()、``、${} 执行命令）。真正安全的路径只有一条：彻底避免 shell 解析。
推荐无条件优先用 subprocess.run()，且必须传入列表形式的参数，禁用 shell=True：
subprocess.run(["ls", "-l", user_input]) # ✅ 安全：参数被当字面量传给 ls
如果非要用 shell=True（比如需要管道、通配符），那就得把整个命令逻辑收归服务端控制，用户输入只能进白名单字段，不能参与拼接。
- 危险写法：
os.system("cat " + filename)、subprocess.run("grep " + keyword, shell=True) - 常见坑：以为
shlex.quote()能兜底所有情况，但它对空字节、Unicode 分隔符、某些 shell 内建命令无效 - 兼容性注意：Windows 下
subprocess.run(..., shell=True)走的是 cmd.exe，行为和 bash 不一致，别跨平台硬套
动态构造命令时如何过滤不可信输入
没有“通用过滤函数”能解决所有命令执行漏洞。过滤策略必须绑定具体命令和参数位置——比如 tar -xf 后面的文件名，要限制为相对路径、不含 ..、不含控制字符；而 convert（ImageMagick）的输入 URL，则必须禁止 https:// 以外的协议，且校验域名白名单。
立即学习“Python免费学习笔记（深入）”；
不要试图用正则“删掉危险字符”，而是用白名单做解析：
- 用
pathlib.Path(filename).resolve().relative_to(base_dir)校验路径是否在允许范围内 - 对命令参数做类型强转再校验：比如端口号转
int后判断是否在 1–65535 - 避免用
str.replace()删除;或&—— 攻击者可换用换行符或\x00绕过
subprocess.Popen() 的 timeout 和 stderr 处理为什么关键
不设 timeout 的 subprocess.Popen() 可能被恶意输入触发无限阻塞（比如传个超长字符串让 grep 回溯爆炸）；不捕获 stderr 则可能泄露调试信息（如完整堆栈、环境变量、绝对路径），给后续攻击铺路。
正确姿势是显式约束资源，并隔离输出流：
proc = subprocess.Popen(cmd_list, stdout=subprocess.PIPE, stderr=subprocess.PIPE, timeout=30)
- timeout 值不能拍脑袋定：要测真实业务负载下的合理上限，太短会误杀正常请求
- 务必用
stderr=subprocess.PIPE，而不是默认继承父进程 stderr，否则错误日志可能混进响应体 - 避免用
proc.communicate()无限制读取大输出，应配合stdout.read(1024*1024)限流
Django/Flask 中调用系统命令的隐藏风险
Web 框架本身不拦命令执行，但它们的请求生命周期会放大问题：比如 Flask 的 request.args.get("file") 看似只是个字符串，一旦进 os.system() 就变成远程代码执行入口；Django 的 get_object_or_404() 返回模型实例，但如果该模型字段存了用户可控的命令片段，照样中招。
核心原则是：任何从 HTTP 请求里拿到的数据，都默认不可信，不能直通子进程。
- 别在视图函数里写
subprocess，抽成独立服务或队列任务，用固定参数模板调用 - 如果必须动态，先做 schema 验证（如用
pydantic.BaseModel），再进命令构造逻辑 - 生产环境禁用
DEBUG=True，它会让异常页面暴露os.environ和完整 traceback
最麻烦的不是不会写安全代码，而是某次重构时把一个看似无害的 os.popen() 从工具模块挪进了 API 视图里，还忘了加参数校验——这种地方最容易漏。
