甲骨文 Java 平台组的首席架构师 Mark Reinhold 指出，甲骨文计划取消 Java 语言主体中的数据序列化/反序列化支持。

序列化即提取数据对象并将其转换为字节流（二进制格式）的过程，因此它可以通过网络传输或保存在数据库中，稍后才以其原始形式将其反序列化。

序列化或反序列化数据本身并非是问题，或者当数据源安全时，它们并非问题本身。这些操作只有在应用和用户提供的数据一起运作时才变得危险。这篇文章中探讨的是后一种情形下的序列化和反序列化操作。

由于反序列化的便捷性，很多高级编程语言支持该功能，但它在 Java 语言中带来的问题最让人头疼，因为它是一系列安全问题的根源。

序列化被指为“糟糕的错误”

Reinhold 表示，1997年在 Java 中引入序列化支持功能的做法是一个“糟糕的错误”。

Reinhold 称，Java 团队目前正在致力于永远清除 Java 主体中的序列化支持功能，不过仍然会通过一个新框架为开发人员提供一个插件系统支持序列化操作。

Reinhold 表示，目前甲骨文尚未确定具体在哪天或者在哪个版本中取消序列化支持功能。

不过在甲骨文这么做之前，很多不想让开发人员或恶意模块调用序列化/反序列化函数的企业和项目负责人能够通过Java 在2016年增加的“序列化过滤器”完全阻止这些操作。

序列化/反序列化安全问题

虽然经由序列化/反序列化操作实施的攻击已经以各种形式存在多年，但它们在2015年初才成为所有人的问题。当时，两名研究员 Chris Frohoff 和 Gabriel Lawrence 在非常流行的 Java 应用 Apache Commons Collection 中发现了一个反序列化缺陷。

Foxglove 安全公司的研究人员在2015年末扩展了初始阶段的工作，展示了攻击者如何能够利用开发人员未正确使用 Apache Commons Collection 库处理反序列化操作的 Java 应用中利用反序列化缺陷。

他们的实验表明，攻击者能够将恶意数据上传到流行的 Java 应用中如 WebLogic、WebSphere、JBoss、Jenkins 和 OpenNMS。这些数据将被序列化并存储到数据库或内存中，但当应用进行反序列化时，应用还会执行其它恶意代码。

这个缺陷在2016年引发了 Java 生态系统的大地震，因为它还影响其它70个 Java 库，而且甚至被用于攻陷 PayPal 服务器。多家组织机构如 Apache、甲骨文、思科、红帽、Jenkins、VMWare、IBM、英特尔、Adobe、惠普和 SolarWinds 都发布补丁修复各自的产品。

这个 Java 反序列化缺陷极其严重，谷歌工程师甚至在工作之外的时间修复了 Java 开源库并通过修复2600多个项目从而限制了缺陷的蔓延。在谷歌内部，这个缺陷被称为“疯狂的小部件 (Mad Gadget)”，不过外界对它的叫法是 “Java 启示录 (Apocalypse)”。

虽然 Java 序列化/反序列化安全问题由来已久，但发生在2015年的 “Java 启示录”唤醒了很多企业和整个 Java 社区，他们开始更多地关注如何序列化以及反序列化数据。

序列化漏洞一直是 Java 面临的大问题

Reinhold 表示，序列化问题很容易会引发三分之一甚至是一半的 Java 已知缺陷。

他的评估基本正确。例如，甲骨文在2018年1月的安全更新中修复了 237 个漏洞，其中28.5%的更新解决的是不安全的反序列化操作问题。

这个问题也在多个公司之间大规模传播。ShiftLeft 公司发布的一份报告指出，大量 SaaS 供应商的 SDK 中出现大量序列化/反序列化缺陷。

去年，一个 Apache Struts (Java) 反序列化漏洞就影响约65%的财富100强公司，说明了序列化数据的实践范围之广以及区区一个漏洞就能让全球规模最大的公司的安全不堪一击。

虽然甲骨文正在解决 Java 中的这个问题，但序列化问题也蛰伏在其它编程环境如 .NET、Ruby 等。

本文由360代码卫士翻译自BleepingComputer

声明：本文来自代码卫士，版权归作者所有。文章内容仅代表作者独立观点，不代表士冗科技立场，转载目的在于传递更多信息。如有侵权，请联系 service@expshell.com。