java 反序列化漏洞

最新推荐文章于 2025-05-11 20:17:12 发布

转载最新推荐文章于 2025-05-11 20:17:12 发布 · 73 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：https://my.oschina.net/u/2308739/blog/614309

本文分析了Apache Commons Collections库中的反序列化漏洞原理及其潜在风险，并提供了漏洞修复建议。通过介绍多种Java应用中序列化的常见场景，文章强调了确保应用程序安全的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2019独角兽企业重金招聘Python工程师标准>>>

漏洞是利用apach commons-collections/

apache 建议升级该jar

https://commons.apache.org/proper/commons-collections/release_3_2_2.html

freebuf也分析可以参考

http://www.freebuf.com/vuls/86566.html

关于反序列化漏洞原理的分析：

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

Java LOVES sending serialized objects all over the place. For example:

In HTTP requests – Parameters, ViewState, Cookies, you name it.
RMI – The extensively used Java RMI protocol is 100% based on serialization
RMI over HTTP – Many Java thick client web apps use this – again 100% serialized objects
JMX – Again, relies on serialized objects being shot over the wire
Custom Protocols – Sending an receiving raw Java objects is the norm – which we’ll see in some of the exploits to come

Okay, so what you ask? Well what if we knew of an object that implemented a “readObject” method that did something dangerous? What if instead of appending an exclamation point to a user defined string, it could be massaged into running a user defined command on the operating system? That would be pretty bad.

Suppose such a vulnerable object existed, but wasn’t part of “core” Java, but instead just part of a library. Think about the requirements for exploitation:

That library would need to be on the Java “classpath”
The application would need to deserialize untrusted user input

We’ve already determined that requirement 2 is very often satisfied. Requirement 1 could be satisfied if we could find such a vulnerability in a commonly used library…

转载于:https://my.oschina.net/u/2308739/blog/614309