尧图网站建设 
CPython 标准库安全考量指南模块级风险清单与防御实践【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpythonPython 的内置电池策略让开发者能快速完成开发但标准库中多个模块在特定使用场景下隐藏着安全陷阱反序列化、配置解析、临时文件与压缩包处理都可能是攻击面。本文以 CPython 官方文档中的 安全考量总索引 为骨架逐项展开各模块的风险成因、缓解手段与官方推荐用法帮助你在编写涉及不可信输入的代码时做出正确的取舍。阅读地图官方如何组织模块安全信息CPython 在标准库文档中维护了一份集中式的安全考量Security Considerations清单入口即 security_warnings.rst。它的定位不是替代各模块的完整文档而是一张风险雷达图——凡是官方认定存在特定安全注意事项的模块都会在这里列出并通过:ref:交叉引用把读者带到各模块文档内的详细安全小节。列表覆盖了三大类问题反序列化 / 任意代码执行风险pickle、shelve、multiprocessing.Connection、logging配置、http.server日志中的控制字符密码学与信任边界误用hashlib的usedforsecurity开关、random与secrets的职责划分、ssl的默认证书校验策略、tempfile.mktemp的竞态缺陷资源耗尽型 DoSxml解析器的实体膨胀攻击、zipfile的解压炸弹、subprocess的 shell 注入面。文档末尾还给出了一条贯穿全局的启动期建议对应 security_warnings.rst 第 35-38 行优先用-I以隔离模式运行 Python无法隔离时用-P或环境变量PYTHONSAFEPATH阻止把当前目录、脚本所在目录或空字符串等潜在不安全路径前置到sys.path从而阻断基于sys.path[0]的模块劫持。下面按技术域分节深入每一类风险并给出可直接落地到工程中的对策。启动期的第一道防线-I、-P 与 PYTHONSAFEPATH官方索引在文末单独强调了进程启动阶段的路径安全。Python 解释器在解析命令行时会把若干路径隐式加入sys.path例如运行脚本时其所在目录、以交互方式启动时的当前目录以及空字符串所代表的当前目录一旦这些位置存在与标准库或第三方库同名的恶意模块import机制就可能加载到攻击者控制的代码。三种措施的定位与取舍如下手段作用适用场景python -I以隔离模式运行将不安全路径排除出sys.path体系运行不受信任的脚本/命令环境可完全受控python -P不把当前目录、脚本目录或空字符串前置到sys.path无法使用完整隔离模式但希望阻止基于路径的模块劫持PYTHONSAFEPATH环境变量设为非零值时与-P等价由环境变量统一管控的部署/容器场景关于这些命令行开关的完整语义可进一步参考 命令行与环境文档。需要留意的是-I的隔离能力最强但它同时会屏蔽用户环境中自定义的若干配置项因此在正式部署前应先在目标环境验证第三方库的可用性。反序列化与数据即代码风险这一组的共同特征是输入字节流一旦被反序列化就可能触发任意代码执行。它们的详细论证散见于 pickle.rst、shelve.rst 与 multiprocessing.rst。pickle默认会导入任意全局对象pickle是 Python 最灵活也最危险的序列化格式。官方文档指出默认情况下反序列化会导入 pickle 数据中出现的任何类或函数pickle.rst 的Restricting Globals一节攻击者只需手工构造数据流即可调用任意全局例如下面这段让os.system(echo hello world)在pickle.loads()时被执行的示例 import pickle pickle.loads(bcos\nsystem\n(Secho hello world\ntR.) hello world 0示例虽无害但同样的手法换成删除文件、反弹 shell 并不困难。官方给出的标准对策是重写Unpickler.find_class做白名单过滤——该钩子在每次请求全局对象类或函数时被调用因此既能彻底禁绝全局也能只放行安全子集。下面是从 pickle.rst 直接取用的受限反序列化器实现import builtins import io import pickle safe_builtins { range, complex, set, frozenset, slice, } class RestrictedUnpickler(pickle.Unpickler): def find_class(self, module, name): # Only allow safe classes from builtins. if module builtins and name in safe_builtins: return getattr(builtins, name) # Forbid everything else. raise pickle.UnpicklingError(global %s.%s is forbidden % (module, name)) def restricted_loads(s): Helper function analogous to pickle.loads(). return RestrictedUnpickler(io.BytesIO(s)).load()工程结论绝不要对不可信来源执行pickle.loads若必须支持受限的数据交换优先改用 JSON 等纯数据格式或参照上例收紧find_class。shelve基于 pickle 的持久化字典同样不可信即不可开shelve把字典语义映射到磁盘文件但其底层存储正是 pickleshelve.rst 第 82-86 行给出明确warning:。因此官方措辞与 pickle 完全一致从不可信来源加载 shelf 文件是不安全的加载 shelf 与加载 pickle 一样可能执行任意代码。凡是可能接触攻击者写入文件的场景例如下载共享的.db缓存都应视为危险操作。multiprocessing.Connection.recv跨进程通道自带自动解包多进程编程里常用Connection.send/Connection.recv在进程间传递消息但官方在 multiprocessing.rst 的recv警告中明确指出Connection.recv会对收到的数据自动执行pickle反序列化。因此除非连接对象是通过multiprocessing.Pipe创建的自己人通道否则必须在send/recv之前先做身份认证multiprocessing模块为此内置了连接认证密钥机制文档Authentication keys一节描述的multiprocessing-auth-keys流程用于确认对端进程的真实身份同一节还提醒进程在读/写管道中途被杀死时管道内数据可能因消息边界错乱而损坏——这也是一种需要在健壮性设计中考量的异常场景。密码学、随机数与传输层安全hashlib用 usedforsecurity 显式声明非安全用途出于对已知不安全或被封禁算法如 MD5、SHA1的合规管控从 Python 3.9 起hashlib所有构造函数都接受一个仅限关键字的usedforsecurity参数默认值为True见 hashlib.rst。当你在某些受限环境例如需要走 FIPS 合规校验的部署中确实要用 MD5 计算校验和这类非密码学场景时将其显式置为False即可放行被拦截的算法import hashlib # 明确声明仅作非密码学的一次性压缩/指纹用途 digest hashlib.md5(bdata, usedforsecurityFalse).hexdigest()该参数的语义是告知解释器此算法不用于安全上下文反之默认True表示算法确实承担安全职责此时受限环境会阻止已知不安全算法运行。另外从源码构建视角看hashlib.rst 记录了 3.12 起的一条实现细节当链接的 OpenSSL 不提供 MD5/SHA1/SHA2/SHA3 中任一算法时CPython 会回退到来自 HACL* 项目的经形式化验证的实现对应仓库内 Modules/_hacl 目录保证算法可用性与实现的独立性。random绝不用于安全用途请改用 secretsPython 的random模块提供的是伪随机数生成器其文档在开头即明确random.rst该模块的伪随机生成器不应被用于安全目的。其可预测性意味着用它生成令牌、密码、密钥、随机 nonce 都会把系统暴露给攻击者。安全随机数请一律改用secrets模块标准库入口在 Lib/secrets.py它封装了操作系统级加密安全随机源适用于生成口令、账号认证、安全令牌等场景。经验法则凡是结果需要保密或不可预测就别碰random。ssl把默认安全交给 create_default_contextssl模块的安全考量ssl.rst 的Security considerations一节核心是最佳默认值哲学客户端场景在无特殊策略要求时官方强烈推荐用ssl.create_default_context()创建上下文。它会加载系统信任的 CA 证书、开启证书校验与主机名校验并挑选相对稳妥的协议与密码套件。官方示例展示了结合 SMTP 的用法 import ssl, smtplib smtp smtplib.SMTP(mail.python.org, port587) context ssl.create_default_context() smtp.starttls(contextcontext) (220, b2.0.0 Ready to start TLS)如果需要客户端证书可再通过SSLContext.load_cert_chain加载。手动构造上下文的陷阱直接调用SSLContext构造函数得到的上下文默认不启用证书校验与主机名校验。文档强调客户端模式下默认的CERT_NONE不认证对端是不安全的应设置CERT_REQUIRED并通过SSLSocket.getpeercert()取得服务端证书后校验其与目标服务是否匹配——对于多数协议这一校验即主机名匹配在开启SSLContext.check_hostname后由底层自动完成。服务端若要用 SSL 层认证客户端同样需要CERT_REQUIRED并校验客户端证书。该节后续还覆盖了协议版本、密码套件等手动配置细节实践中优先遵循能用create_default_context就别手搓上下文的原则可规避绝大多数常见 TLS 误配置。网络服务、子进程与外部输入边界http.server仅限开发调试勿当生产服务器http.server模块http.server.rst 的Security considerations定位清晰不适合生产使用只实现了基本安全检查。官方列举了三类典型问题SimpleHTTPRequestHandler处理请求时会跟随符号链接使指定目录之外的文件也可能被伺服出去——这是静态文件服务场景最直接的越权路径BaseHTTPRequestHandler.send_header与send_response_only假定输入已净化不会校验 CRLF 序列不可信输入可能引发 HTTP 响应头注入早期版本不清理写入 stderr 日志中的控制字符远端客户端可通过连接向运维终端注入转义序列Python 3.12 起日志已做控制字符清洗。python -m http.server仅适合本地联调或隔离环境中的临时文件共享切勿直接暴露到公网。subprocess默认不经过 shell就守住了一半subprocess的设计决策是除非显式指定否则不会隐式调用系统 shellsubprocess.rst 的Security Considerations。这意味着传给子进程的参数即便包含 shell 元字符;、|、、$()等也只是普通字符天然免疫一大类命令注入。需要遵守的规则是默认保持shellFalse把命令写成参数列表[ls, -l, user_input]而不是拼字符串再交给 shell若确实需要shellTrue例如执行含管道/重定向的复合命令那么对不可信输入中的空白与元字符做正确引号转义就成了应用自身的责任。在支持shlex.quote的平台shlex 文档 有平台差异提示可借助它完成转义一个易被忽视的 Windows 特例操作系统可能无视传入参数、直接在系统 shell 中启动.bat/.cmd批处理文件导致参数按 shell 规则解析而 Python 未做任何转义。若确需用不可信来源的参数启动批处理文件官方建议显式传shellTrue让 Python 代为转义特殊字符。logging.config配置文件经过 eval慎对不可信来源日志配置的功能设计强调便利性——它允许把配置文件中的文本转换成 Python 对象导入用户自定义模块中的可调用对象并按配置参数调用。这既是灵活性来源也是风险所在。相关警告集中在 logging.config.rst 的listen()小节listen(port, verifyNone)在localhost上开一个套接字监听把收到的配置通过eval等机制应用因此本质上是配置即代码它虽然只绑定回环地址、不直接接受远程连接但在多用户共享机器上恶意用户只要连上受害者的监听套接字并发送一段恶意配置就可能在受害者进程的账户下执行任意代码——默认端口让这件事尤其容易换端口也不能根治缓解手段是使用verify参数提供一个可调用对象对跨套接字收到的字节做验签/解密例如先加密并签名再发送verify返回字节表示放行、返回None表示丢弃从而拒绝无法识别的配置被应用该参数自 Python 3.4 加入同一模块更上层的安全考量logging.config.rst把范围扩展到了所有配置文件加载由于dictConfig的字典语法支持从用户模块导入可调用对象并用配置中的参数调用来自不可信来源的日志配置文件必须极度谨慎对待加载前要确认其不会造成危害。文件系统、临时文件与压缩归档tempfile别再使用有竞态缺陷的 mktemp历史上一度流行的临时文件写法是先用mktemp()生成文件名再手工创建文件。官方在 tempfile.rst 的Deprecated functions and variables中解释其为何不安全两次调用之间存在时间窗口另一进程可能抢先创建同名文件导致符号链接替换、内容劫持等竞态攻击。自 Python 2.3 起mktemp()即被弃用正确做法是把取名与创建合并为一步——即使用mkstemp()及同族 API。若需要的是具名文件随后再删可用NamedTemporaryFile并传deleteFalse f NamedTemporaryFile(deleteFalse) f.name /tmp/tmptjujjt f.write(bHello World!\n) 13 f.close() os.unlink(f.name) os.path.exists(f.name) False要点mktemp()只能保证调用时刻文件不存在无法保证创建时刻仍归你所有任何依赖旧 API 的代码都应及时迁移。zipfile恶意归档可能耗尽磁盘提取前先想清楚zipfile的安全说明zipfile.rst 的Resources limitations等小节把注意力放在解压的后果上资源限制内存或磁盘不足会导致解压失败而攻击者精心构造的解压炸弹ZIP bomb能让小体积归档在解压后占据巨大磁盘空间造成磁盘容量耗尽中断处理解压过程中被 Ctrl-C 或进程被杀会留下不完整的解压结果因此写批处理脚本时应考虑解压的原子性与可重入性默认行为认知同样的归档解压两次会不询问地覆盖文件——结合符号链接、路径穿越等历史问题接收外部.zip时应先审查成员路径并明确覆盖策略。xml内置解析器的实体膨胀与解压炸弹防线xml安全小节xml.rst给出了一句总纲攻击者可以滥用 XML 特性实施拒绝服务、访问本地文件、向其他机器发起网络连接、绕过防火墙——只要被解析的 XML 由攻击者控制。Python 内置 XML 解析器基于 Expatlibexpat官方保证默认情况下 Expat 本身不会访问本地文件或建立网络连接真正的威胁集中在以下几类 DoS 攻击上Billion Laughs / 指数级实体扩展层层嵌套的实体互相引用、指数级放大最终展开出数 GB 文本耗尽内存与 CPU二次方膨胀实体扩展不靠嵌套而是反复重复一个上千字符的大实体效率虽不如指数级却能绕过禁止深层嵌套的解析器防御解压炸弹对能解析 gzip、LZMA 等压缩 XML 流的库均适用攻击者最多可把传输数据量缩小三个数量级以上超大 tokenExpat 需对未完成的 token 反复重解析缺少保护时会产生二次方级运行时间即 CVE-2023-52425Python 侧通过依赖 Expat 2.6.0 引入的防护来缓解。文档还特别点名xmlrpc对解压炸弹是已知易受攻击的。实践建议包括核实运行环境中pyexpat.EXPAT_VERSION是否达到 2.7.2低于该版本可能受 Billion Laughs / 二次方膨胀 / 大 token / 动态内存滥用影响解析前对文档大小与实体结构设限避免直接解析来自不可信源的压缩 XML。CPython 是否使用内置的 Expat 副本取决于构建时的配置对应--with-system-expat选项。附录模块风险与对策速查模块主要风险官方推荐对策详细出处pickle反序列化任意代码执行白名单find_class优先 JSONpickle.rstshelvepickle 底层的任意代码执行不可信 shelf 一律不加载shelve.rstmultiprocessingrecv()自动解包仅信任Pipe对端先做连接认证multiprocessing.rsthashlib受限环境下不安全算法被拦截非安全用途传usedforsecurityFalsehashlib.rstrandom伪随机可预测安全用途改用secretsrandom.rstssl默认无证书/主机名校验create_default_context()CERT_REQUIREDssl.rsthttp.server符号链接越权、CRLF 头注入、日志控制字符仅开发用途勿生产部署http.server.rstlogging.config配置经eval/对象导入执行代码不可信配置不加载listen()用verifylogging.config.rstsubprocessshellTrue命令注入默认shellFalse必要时shlex.quotesubprocess.rsttempfilemktemp()竞态mkstemp()/NamedTemporaryFiletempfile.rstxml实体膨胀、解压炸弹、大 token DoS核实 Expat 版本限制输入规模xml.rstzipfileZIP bomb 磁盘耗尽、覆盖审查成员明确资源与覆盖策略zipfile.rstbase64编码层通用安全考量生产代码对照 RFC 4648 第 12 节审查base64.rst纵览整份清单可以提炼出一条贯穿 CPython 安全设计的主线凡是把字节/文本输入解释为对象/命令/代码的边界pickle、shelve、multiprocessing 消息、logging 配置、shell、XML都必须先回答输入可信吗回答不了时就采用官方提供的收敛手段——白名单钩子、verify回调、显式shellFalse或彻底更换数据格式。把 security_warnings.rst 当作每次安全评审的 checklist再回到各模块文档的Security considerations小节核对细节即可在标准库的使用中守住大多数默认防线。【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CPython 标准库安全考量指南：模块级风险清单与防御实践
CPython 标准库安全考量指南模块级风险清单与防御实践【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpythonPython 的内置电池策略让开发者能快速完成开发但标准库中多个模块在特定使用场景下隐藏着安全陷阱反序列化、配置解析、临时文件与压缩包处理都可能是攻击面。本文以 CPython 官方文档中的 安全考量总索引 为骨架逐项展开各模块的风险成因、缓解手段与官方推荐用法帮助你在编写涉及不可信输入的代码时做出正确的取舍。阅读地图官方如何组织模块安全信息CPython 在标准库文档中维护了一份集中式的安全考量Security Considerations清单入口即 security_warnings.rst。它的定位不是替代各模块的完整文档而是一张风险雷达图——凡是官方认定存在特定安全注意事项的模块都会在这里列出并通过:ref:交叉引用把读者带到各模块文档内的详细安全小节。列表覆盖了三大类问题反序列化 / 任意代码执行风险pickle、shelve、multiprocessing.Connection、logging配置、http.server日志中的控制字符密码学与信任边界误用hashlib的usedforsecurity开关、random与secrets的职责划分、ssl的默认证书校验策略、tempfile.mktemp的竞态缺陷资源耗尽型 DoSxml解析器的实体膨胀攻击、zipfile的解压炸弹、subprocess的 shell 注入面。文档末尾还给出了一条贯穿全局的启动期建议对应 security_warnings.rst 第 35-38 行优先用-I以隔离模式运行 Python无法隔离时用-P或环境变量PYTHONSAFEPATH阻止把当前目录、脚本所在目录或空字符串等潜在不安全路径前置到sys.path从而阻断基于sys.path[0]的模块劫持。下面按技术域分节深入每一类风险并给出可直接落地到工程中的对策。启动期的第一道防线-I、-P 与 PYTHONSAFEPATH官方索引在文末单独强调了进程启动阶段的路径安全。Python 解释器在解析命令行时会把若干路径隐式加入sys.path例如运行脚本时其所在目录、以交互方式启动时的当前目录以及空字符串所代表的当前目录一旦这些位置存在与标准库或第三方库同名的恶意模块import机制就可能加载到攻击者控制的代码。三种措施的定位与取舍如下手段作用适用场景python -I以隔离模式运行将不安全路径排除出sys.path体系运行不受信任的脚本/命令环境可完全受控python -P不把当前目录、脚本目录或空字符串前置到sys.path无法使用完整隔离模式但希望阻止基于路径的模块劫持PYTHONSAFEPATH环境变量设为非零值时与-P等价由环境变量统一管控的部署/容器场景关于这些命令行开关的完整语义可进一步参考 命令行与环境文档。需要留意的是-I的隔离能力最强但它同时会屏蔽用户环境中自定义的若干配置项因此在正式部署前应先在目标环境验证第三方库的可用性。反序列化与数据即代码风险这一组的共同特征是输入字节流一旦被反序列化就可能触发任意代码执行。它们的详细论证散见于 pickle.rst、shelve.rst 与 multiprocessing.rst。pickle默认会导入任意全局对象pickle是 Python 最灵活也最危险的序列化格式。官方文档指出默认情况下反序列化会导入 pickle 数据中出现的任何类或函数pickle.rst 的Restricting Globals一节攻击者只需手工构造数据流即可调用任意全局例如下面这段让os.system(echo hello world)在pickle.loads()时被执行的示例 import pickle pickle.loads(bcos\nsystem\n(Secho hello world\ntR.) hello world 0示例虽无害但同样的手法换成删除文件、反弹 shell 并不困难。官方给出的标准对策是重写Unpickler.find_class做白名单过滤——该钩子在每次请求全局对象类或函数时被调用因此既能彻底禁绝全局也能只放行安全子集。下面是从 pickle.rst 直接取用的受限反序列化器实现import builtins import io import pickle safe_builtins { range, complex, set, frozenset, slice, } class RestrictedUnpickler(pickle.Unpickler): def find_class(self, module, name): # Only allow safe classes from builtins. if module builtins and name in safe_builtins: return getattr(builtins, name) # Forbid everything else. raise pickle.UnpicklingError(global %s.%s is forbidden % (module, name)) def restricted_loads(s): Helper function analogous to pickle.loads(). return RestrictedUnpickler(io.BytesIO(s)).load()工程结论绝不要对不可信来源执行pickle.loads若必须支持受限的数据交换优先改用 JSON 等纯数据格式或参照上例收紧find_class。shelve基于 pickle 的持久化字典同样不可信即不可开shelve把字典语义映射到磁盘文件但其底层存储正是 pickleshelve.rst 第 82-86 行给出明确warning:。因此官方措辞与 pickle 完全一致从不可信来源加载 shelf 文件是不安全的加载 shelf 与加载 pickle 一样可能执行任意代码。凡是可能接触攻击者写入文件的场景例如下载共享的.db缓存都应视为危险操作。multiprocessing.Connection.recv跨进程通道自带自动解包多进程编程里常用Connection.send/Connection.recv在进程间传递消息但官方在 multiprocessing.rst 的recv警告中明确指出Connection.recv会对收到的数据自动执行pickle反序列化。因此除非连接对象是通过multiprocessing.Pipe创建的自己人通道否则必须在send/recv之前先做身份认证multiprocessing模块为此内置了连接认证密钥机制文档Authentication keys一节描述的multiprocessing-auth-keys流程用于确认对端进程的真实身份同一节还提醒进程在读/写管道中途被杀死时管道内数据可能因消息边界错乱而损坏——这也是一种需要在健壮性设计中考量的异常场景。密码学、随机数与传输层安全hashlib用 usedforsecurity 显式声明非安全用途出于对已知不安全或被封禁算法如 MD5、SHA1的合规管控从 Python 3.9 起hashlib所有构造函数都接受一个仅限关键字的usedforsecurity参数默认值为True见 hashlib.rst。当你在某些受限环境例如需要走 FIPS 合规校验的部署中确实要用 MD5 计算校验和这类非密码学场景时将其显式置为False即可放行被拦截的算法import hashlib # 明确声明仅作非密码学的一次性压缩/指纹用途 digest hashlib.md5(bdata, usedforsecurityFalse).hexdigest()该参数的语义是告知解释器此算法不用于安全上下文反之默认True表示算法确实承担安全职责此时受限环境会阻止已知不安全算法运行。另外从源码构建视角看hashlib.rst 记录了 3.12 起的一条实现细节当链接的 OpenSSL 不提供 MD5/SHA1/SHA2/SHA3 中任一算法时CPython 会回退到来自 HACL* 项目的经形式化验证的实现对应仓库内 Modules/_hacl 目录保证算法可用性与实现的独立性。random绝不用于安全用途请改用 secretsPython 的random模块提供的是伪随机数生成器其文档在开头即明确random.rst该模块的伪随机生成器不应被用于安全目的。其可预测性意味着用它生成令牌、密码、密钥、随机 nonce 都会把系统暴露给攻击者。安全随机数请一律改用secrets模块标准库入口在 Lib/secrets.py它封装了操作系统级加密安全随机源适用于生成口令、账号认证、安全令牌等场景。经验法则凡是结果需要保密或不可预测就别碰random。ssl把默认安全交给 create_default_contextssl模块的安全考量ssl.rst 的Security considerations一节核心是最佳默认值哲学客户端场景在无特殊策略要求时官方强烈推荐用ssl.create_default_context()创建上下文。它会加载系统信任的 CA 证书、开启证书校验与主机名校验并挑选相对稳妥的协议与密码套件。官方示例展示了结合 SMTP 的用法 import ssl, smtplib smtp smtplib.SMTP(mail.python.org, port587) context ssl.create_default_context() smtp.starttls(contextcontext) (220, b2.0.0 Ready to start TLS)如果需要客户端证书可再通过SSLContext.load_cert_chain加载。手动构造上下文的陷阱直接调用SSLContext构造函数得到的上下文默认不启用证书校验与主机名校验。文档强调客户端模式下默认的CERT_NONE不认证对端是不安全的应设置CERT_REQUIRED并通过SSLSocket.getpeercert()取得服务端证书后校验其与目标服务是否匹配——对于多数协议这一校验即主机名匹配在开启SSLContext.check_hostname后由底层自动完成。服务端若要用 SSL 层认证客户端同样需要CERT_REQUIRED并校验客户端证书。该节后续还覆盖了协议版本、密码套件等手动配置细节实践中优先遵循能用create_default_context就别手搓上下文的原则可规避绝大多数常见 TLS 误配置。网络服务、子进程与外部输入边界http.server仅限开发调试勿当生产服务器http.server模块http.server.rst 的Security considerations定位清晰不适合生产使用只实现了基本安全检查。官方列举了三类典型问题SimpleHTTPRequestHandler处理请求时会跟随符号链接使指定目录之外的文件也可能被伺服出去——这是静态文件服务场景最直接的越权路径BaseHTTPRequestHandler.send_header与send_response_only假定输入已净化不会校验 CRLF 序列不可信输入可能引发 HTTP 响应头注入早期版本不清理写入 stderr 日志中的控制字符远端客户端可通过连接向运维终端注入转义序列Python 3.12 起日志已做控制字符清洗。python -m http.server仅适合本地联调或隔离环境中的临时文件共享切勿直接暴露到公网。subprocess默认不经过 shell就守住了一半subprocess的设计决策是除非显式指定否则不会隐式调用系统 shellsubprocess.rst 的Security Considerations。这意味着传给子进程的参数即便包含 shell 元字符;、|、、$()等也只是普通字符天然免疫一大类命令注入。需要遵守的规则是默认保持shellFalse把命令写成参数列表[ls, -l, user_input]而不是拼字符串再交给 shell若确实需要shellTrue例如执行含管道/重定向的复合命令那么对不可信输入中的空白与元字符做正确引号转义就成了应用自身的责任。在支持shlex.quote的平台shlex 文档 有平台差异提示可借助它完成转义一个易被忽视的 Windows 特例操作系统可能无视传入参数、直接在系统 shell 中启动.bat/.cmd批处理文件导致参数按 shell 规则解析而 Python 未做任何转义。若确需用不可信来源的参数启动批处理文件官方建议显式传shellTrue让 Python 代为转义特殊字符。logging.config配置文件经过 eval慎对不可信来源日志配置的功能设计强调便利性——它允许把配置文件中的文本转换成 Python 对象导入用户自定义模块中的可调用对象并按配置参数调用。这既是灵活性来源也是风险所在。相关警告集中在 logging.config.rst 的listen()小节listen(port, verifyNone)在localhost上开一个套接字监听把收到的配置通过eval等机制应用因此本质上是配置即代码它虽然只绑定回环地址、不直接接受远程连接但在多用户共享机器上恶意用户只要连上受害者的监听套接字并发送一段恶意配置就可能在受害者进程的账户下执行任意代码——默认端口让这件事尤其容易换端口也不能根治缓解手段是使用verify参数提供一个可调用对象对跨套接字收到的字节做验签/解密例如先加密并签名再发送verify返回字节表示放行、返回None表示丢弃从而拒绝无法识别的配置被应用该参数自 Python 3.4 加入同一模块更上层的安全考量logging.config.rst把范围扩展到了所有配置文件加载由于dictConfig的字典语法支持从用户模块导入可调用对象并用配置中的参数调用来自不可信来源的日志配置文件必须极度谨慎对待加载前要确认其不会造成危害。文件系统、临时文件与压缩归档tempfile别再使用有竞态缺陷的 mktemp历史上一度流行的临时文件写法是先用mktemp()生成文件名再手工创建文件。官方在 tempfile.rst 的Deprecated functions and variables中解释其为何不安全两次调用之间存在时间窗口另一进程可能抢先创建同名文件导致符号链接替换、内容劫持等竞态攻击。自 Python 2.3 起mktemp()即被弃用正确做法是把取名与创建合并为一步——即使用mkstemp()及同族 API。若需要的是具名文件随后再删可用NamedTemporaryFile并传deleteFalse f NamedTemporaryFile(deleteFalse) f.name /tmp/tmptjujjt f.write(bHello World!\n) 13 f.close() os.unlink(f.name) os.path.exists(f.name) False要点mktemp()只能保证调用时刻文件不存在无法保证创建时刻仍归你所有任何依赖旧 API 的代码都应及时迁移。zipfile恶意归档可能耗尽磁盘提取前先想清楚zipfile的安全说明zipfile.rst 的Resources limitations等小节把注意力放在解压的后果上资源限制内存或磁盘不足会导致解压失败而攻击者精心构造的解压炸弹ZIP bomb能让小体积归档在解压后占据巨大磁盘空间造成磁盘容量耗尽中断处理解压过程中被 Ctrl-C 或进程被杀会留下不完整的解压结果因此写批处理脚本时应考虑解压的原子性与可重入性默认行为认知同样的归档解压两次会不询问地覆盖文件——结合符号链接、路径穿越等历史问题接收外部.zip时应先审查成员路径并明确覆盖策略。xml内置解析器的实体膨胀与解压炸弹防线xml安全小节xml.rst给出了一句总纲攻击者可以滥用 XML 特性实施拒绝服务、访问本地文件、向其他机器发起网络连接、绕过防火墙——只要被解析的 XML 由攻击者控制。Python 内置 XML 解析器基于 Expatlibexpat官方保证默认情况下 Expat 本身不会访问本地文件或建立网络连接真正的威胁集中在以下几类 DoS 攻击上Billion Laughs / 指数级实体扩展层层嵌套的实体互相引用、指数级放大最终展开出数 GB 文本耗尽内存与 CPU二次方膨胀实体扩展不靠嵌套而是反复重复一个上千字符的大实体效率虽不如指数级却能绕过禁止深层嵌套的解析器防御解压炸弹对能解析 gzip、LZMA 等压缩 XML 流的库均适用攻击者最多可把传输数据量缩小三个数量级以上超大 tokenExpat 需对未完成的 token 反复重解析缺少保护时会产生二次方级运行时间即 CVE-2023-52425Python 侧通过依赖 Expat 2.6.0 引入的防护来缓解。文档还特别点名xmlrpc对解压炸弹是已知易受攻击的。实践建议包括核实运行环境中pyexpat.EXPAT_VERSION是否达到 2.7.2低于该版本可能受 Billion Laughs / 二次方膨胀 / 大 token / 动态内存滥用影响解析前对文档大小与实体结构设限避免直接解析来自不可信源的压缩 XML。CPython 是否使用内置的 Expat 副本取决于构建时的配置对应--with-system-expat选项。附录模块风险与对策速查模块主要风险官方推荐对策详细出处pickle反序列化任意代码执行白名单find_class优先 JSONpickle.rstshelvepickle 底层的任意代码执行不可信 shelf 一律不加载shelve.rstmultiprocessingrecv()自动解包仅信任Pipe对端先做连接认证multiprocessing.rsthashlib受限环境下不安全算法被拦截非安全用途传usedforsecurityFalsehashlib.rstrandom伪随机可预测安全用途改用secretsrandom.rstssl默认无证书/主机名校验create_default_context()CERT_REQUIREDssl.rsthttp.server符号链接越权、CRLF 头注入、日志控制字符仅开发用途勿生产部署http.server.rstlogging.config配置经eval/对象导入执行代码不可信配置不加载listen()用verifylogging.config.rstsubprocessshellTrue命令注入默认shellFalse必要时shlex.quotesubprocess.rsttempfilemktemp()竞态mkstemp()/NamedTemporaryFiletempfile.rstxml实体膨胀、解压炸弹、大 token DoS核实 Expat 版本限制输入规模xml.rstzipfileZIP bomb 磁盘耗尽、覆盖审查成员明确资源与覆盖策略zipfile.rstbase64编码层通用安全考量生产代码对照 RFC 4648 第 12 节审查base64.rst纵览整份清单可以提炼出一条贯穿 CPython 安全设计的主线凡是把字节/文本输入解释为对象/命令/代码的边界pickle、shelve、multiprocessing 消息、logging 配置、shell、XML都必须先回答输入可信吗回答不了时就采用官方提供的收敛手段——白名单钩子、verify回调、显式shellFalse或彻底更换数据格式。把 security_warnings.rst 当作每次安全评审的 checklist再回到各模块文档的Security considerations小节核对细节即可在标准库的使用中守住大多数默认防线。【免费下载链接】cpythonThe Python programming language项目地址: https://gitcode.com/GitHub_Trending/cp/cpython创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考