OWASP Top 10 2017 A8:2017 不安全反序列化(Insecure Deserialization)深度解析:从 rO0 签名到 PHP Cookie 篡改的攻防实战
发布时间:2026/10/10 17:53:45 锦皓数字建站
深度解析:从 rO0 签名到 PHP Cookie 篡改的攻防实战`)
应用安全【免费下载链接】Top10Official OWASP Top 10 Document Repository项目地址https://gitcode.com/gh_mirrors/top/Top10点击查看免费下载导读本文以 OWASP Top 10 官方仓库 2017 版中的 A8:2017 不安全反序列化土耳其语版 为骨架结合 英文原版、风险因子说明 与 数据方法论 等仓库资料展开。你将掌握反序列化漏洞的产生原理、两类典型攻击形态远程代码执行与数据篡改、OWASP 官方给出的六条防护措施以及 Java 与 PHP 两大生态下的真实攻击场景与防御落地方法。一、背景A8:2017 是如何进入 Top 10 的反序列化漏洞并非 2017 年才出现但它是 OWASP Top 10 2017 版中两个由社区投票新增的类别之一另一个是 A10:2017-不充分的日志与监控。根据仓库内 发布说明土耳其语版 的描述OWASP 就候选漏洞类别咨询了社区在评估了 500 多份回复后将这两类漏洞纳入了 Top 10。更详细的定量依据记录在 数据与方法论 中2017 年 8 月 2 日至 9 月 18 日期间OWASP 面向行业开展了排名调查共收集 516 份回复。其中不可信数据反序列化Deserialization of Untrusted Data[CWE-502]以 514 分排名第三仅次于隐私信息泄露748 分与加密失败584 分经风险评级后正式成为A8:2017-Insecure Deserialization。从风险因子表见 风险因子详情 对应的 0xc1-risk-factors.md可以查到 OWASP 对 A8 的官方评分| 威胁代理 | 可利用性 | 漏洞普遍性 | 漏洞可检测性 | 技术影响 | 业务影响 | | -- | -- | -- | -- | -- | -- | | 应用特定 | 难度 1较难 | 普遍性 2常见 | 可检测性 2中等 | 技术影响 3严重 | 取决于应用与数据的保护需求 |需要注意的是OWASP 官方明确说明该类别是基于行业调查而非可量化数据纳入 Top 10 的。当时一些工具虽能发现反序列化缺陷但通常需要人工协助来验证问题随着检测工具的发展其普遍性数据预计会逐步上升。二、什么是反序列化漏洞2.1 序列化与反序列化的基本概念序列化Serialization是将内存中的对象转换为字节流、字符串或可传输格式的过程反序列化Deserialization则是其逆过程即将收到的数据还原为内存对象。这套机制被广泛应用于各类软件系统中官方文档列举了典型使用场景远程过程调用与进程间通信RPC/IPC线路协议、Web 服务、消息代理Message Broker缓存 / 持久化Caching/Persistence数据库、缓存服务器、文件系统HTTP Cookie、HTML 表单参数、API 认证令牌2.2 漏洞的本质信任了不该信任的数据反序列化漏洞的核心在于应用在还原对象时无差别信任了攻击者提供或篡改的数据。正如 A8 文档土耳其语版 开门见山指出的如果应用程序和 API 对攻击者提供的恶意或经过篡改的对象进行反序列化则该应用存在此漏洞。反序列化过程本质上是在凭空根据输入数据构建内存对象这个过程会触发类的构造器、属性赋值、方法调用等逻辑。一旦输入可控攻击者就能操纵这些逻辑从而突破应用预期。三、两类主要攻击形态官方文档将反序列化攻击归纳为两种类型3.1 对象与数据结构相关攻击→ 远程代码执行当应用环境中存在在反序列化期间或之后可改变行为的类时攻击者可以通过精心构造的序列化数据修改应用逻辑甚至实现任意远程代码执行RCE。这是反序列化漏洞最严重的后果——RCE 是所有攻击类型中最危险的一种其业务影响取决于应用与数据的保护需求。3.2 典型数据篡改攻击→ 越权与提权攻击者沿用现有的数据结构仅篡改其中的内容例如修改序列化对象中的角色字段、用户 ID、权限标记等从而实施与访问控制相关的攻击如越权、提权、重放攻击。A8 在整个 Top 10 列表中的定位也可印证这一点——Top 10 风险总览英文版 对 A8 的描述是不安全的反序列化通常导致远程代码执行。即使反序列化缺陷没有导致远程代码执行也可被用来实施重放攻击、注入攻击和提权攻击。四、如何防护OWASP 官方防御清单官方文档明确指出唯一安全的架构模式是不接受来自不可信来源的序列化对象或使用仅允许原始数据类型primitive data types的序列化媒介。如果做不到这一点则应考虑以下一条或多条措施原文六条逐条展开完整性校验数字签名对任何序列化对象实施完整性检查如数字签名防止恶意对象创建或数据篡改。签名密钥必须妥善保管校验失败即拒绝反序列化。严格类型约束在反序列化过程中、对象创建之前强制实施严格的类型限制——因为代码通常只期望一组可定义的类。需注意官方文档特别警示该技术的绕过手段已被证明存在因此不能仅依赖这一条。隔离与降权运行尽可能将执行反序列化的代码隔离并在低权限环境中运行缩小被攻破后的破坏半径。记录异常与失败对反序列化异常和失败进行日志记录例如传入类型与预期类型不符、反序列化抛出异常等情况为事后分析与告警提供依据。限制或监控网络连接限制或监控执行反序列化的容器或服务器的入站与出站网络连接阻断攻击者建立外连如反弹 shell、数据外传。持续监控与告警对反序列化行为进行监控当某个用户持续、异常频繁地触发反序列化时产生告警。这六条措施分别对应**防篡改1、防构造2、降影响3、可追溯4、断外连5、可感知6**六个维度构成了纵深防御的完整闭环。五、攻击场景实战剖析5.1 场景一React Spring Boot 微服务中的 Java 反序列化 RCE场景设定一个 React 应用调用一组 Spring Boot 微服务。开发团队以函数式编程自居力求代码不可变immutable于是想出的方案是将用户状态序列化并在每次请求中来回传递。攻击链条攻击者截获请求识别出序列化数据的 Java 对象签名rO0这是 Java 原生序列化格式的 Base64 编码魔数对应十六进制AC ED 00 05几乎等同于这是 Java 序列化对象的标识。攻击者使用Java Serial Killer等公开工具向应用服务器提交精心构造的恶意序列化载荷。应用服务器在反序列化该载荷时触发了可利用的 gadget 链如ObjectInputStream 存在危险readObject的类库最终在应用服务器上获得远程代码执行。关键教训将用户可控的状态以 Java 原生序列化格式来回传递等于把反序列化的入口直接暴露给攻击者。任何接收外部输入的ObjectInputStream.readObject()调用都是潜在的攻击面。marshalsec 等项目官方文档的外部参考系统地研究了 Java 各反序列化器的安全问题印证了此类攻击的普遍性。5.2 场景二PHP 对象序列化 Cookie 篡改提权场景设定一个 PHP 论坛使用 PHP 对象序列化保存一个超级Cookie其中包含用户 ID、角色、密码哈希及其他状态信息。原始 Cookie 如下a:4:{i:0;i:132;i:1;s:7:Mallory;i:2;s:4:user;i:3;s:32:b6a8b3bea87fe0e05022f8f3c88bc960;}这是 PHPserialize()的输出含义为一个包含 4 个元素的数组——i:0;i:132下标 0整数值 132用户 IDi:1;s:7:Mallory下标 17 字符字符串 Mallory用户名i:2;s:4:user下标 24 字符字符串 user角色i:3;s:32:b6a8b3bea87fe0e05022f8f3c88bc960下标 332 字符字符串密码哈希攻击过程由于 Cookie 内容未经加密与签名保护攻击者直接修改序列化对象把自己变成管理员a:4:{i:0;i:1;i:1;s:5:Alice;i:2;s:5:admin;i:3;s:32:b6a8b3bea87fe0e05022f8f3c88bc960;}改动之处非常直观用户 ID 从132改为1管理员 ID用户名从Mallory改为Alice角色从user改为admin长度前缀同步从s:4改为s:5密码哈希保持不变攻击结果应用在下次请求反序列化该 Cookie 时将攻击者识别为管理员用户攻击者由此获得管理员权限。这正是文档定义的**第二类攻击数据篡改型**的典型演示——数据结构完全合法、格式完全正确仅仅是内容被换成了高权限值。关键教训PHP 的serialize()/unserialize()处理 Cookie、表单参数等客户端可控数据时必须配合allowed_classes白名单限制、HMAC 签名或加密否则任何字段角色、ID、价格、配额……都可被篡改。六、开发者行动清单结合官方文档与仓库资料给出可落地的检查与修复清单自查清单评估是否易受攻击应用是否对来自客户端Cookie、表单、请求体的序列化数据执行反序列化是否使用了 Java 原生序列化ObjectInputStream、PHPunserialize()、Pythonpickle、RubyMarshal等存在已知风险的机制处理不可信输入反序列化后的对象是否直接参与权限判断、业务逻辑或命令执行序列化数据在传输/存储中是否有完整性保护签名/HMAC修复优先级架构层不接受不可信来源的序列化对象改用 JSON 等仅含原始数据类型的格式。输入层白名单类型约束 数字签名完整性校验两者结合不单独依赖任一。运行层反序列化代码隔离运行、低权限账户、限制网络外连。观测层异常日志、监控与持续反序列化告警呼应 A10:2017-不充分的日志与监控 的要求——没有日志攻击将无法被发现。七、参考资料本文内容主要基于 OWASP Top 10 2017 官方仓库以下文件可按需深入阅读A8:2017 不安全反序列化土耳其语版本文主体A8:2017 Insecure Deserialization英文原版Top 10 风险总览英文版风险因子说明英文版风险评级方法论说明英文版数据与方法论A8 进入 Top 10 的投票依据英文版发布说明2013 到 2017 的变化土耳其语版简介Top 10 的项目背景土耳其语版关联标准该漏洞对应 CWE-502不可信数据反序列化。在后续的 2021 版文档 中反序列化相关议题被并入 A08:2021-软件与数据完整性故障Software and Data Integrity Failures可见此类风险在现代应用安全中始终占据重要位置。赞分享应用安全【免费下载链接】Top10Official OWASP Top 10 Document Repository项目地址https://gitcode.com/gh_mirrors/top/Top10点击查看免费下载相关推荐OWASP Top 10 2017 A8: 不安全的反序列化Insecure Deserialization深度解析与防护实战OWASP Top 10 2017 A8: 不安全的反序列化Insecure Deserialization深度解析与防护实战 本文基于 OWASP Top应用安全OptiScaler 超分完全指南3 步给任意显卡换上 AI 超分引擎OptiScaler 超分完全指南3 步给任意显卡换上 AI 超分引擎 新 3A 开高画质老显卡直接掉到 20 帧DLSS 还只对 N 卡开放OptiS应用安全OWASP Top 10 2017 深度解析A8 不安全反序列化Insecure Deserialization原理、攻击场景与防护指南OWASP Top 10 2017 深度解析A8 不安全反序列化Insecure Deserialization原理、攻击场景与防护指南 导读 本文以 O应用安全上一篇rspec-given 不止用于测试在业务代码中使用 Precondition 与 Postcondition 断言下一篇多平台直播全攻略3大场景5个锦囊带你轻松掌握OBS Multi RTMP创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
锦
锦皓数字建站
深耕本土企业品牌数字化升级,专注原创端正雅致商务官网,从视觉设计到稳定运维全程保驾护航。