Python 命令执行漏洞的防范

安全边界在于禁用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 视图里，还忘了加参数校验——这种地方最容易漏。