java_cc链7

cc链7依旧是触发LazyMap的get方法的另一种思路，主要是采用Hashtable的hash碰撞

java_cc链6

这是一条除BadAttributeValueExpException以外调用LazyMa.get方法的链子，也就是cc链5的变形

java_cc链5

这里我们又回到了去触发 LazyMap.get()，只不过我们改变了 LazyMap.get() 的触发方式，不再和 CC1 和 CC3 一样借助 AnnotationInvocationHandler 的反序列化触发。

java_cc链4

上面 CC2 说了因为 CommonsCollections4 除4.0的其他版本去掉了 InvokerTransformer 的 Serializable 继承，导致无法序列化。所以我们是否可以不使用 InvokerTransformer 呢？于是便有了 CC4，其实cc链4就是cc2链中InvokerTransformer替换为 InstantiateTransformer，看起来有点类似cc2与cc3的结合

DC-2

老样子，先arpscan扫一下

1

arp-scan -l

java_cc链3

cc3链和cc1想法还是很相似的，然后构造恶意类和调用使用了不同的两个新类，这里感觉cc3链有一些像cc1链的变种，就像是给你一些绕过的操作，有点像cc1和cc2的结合体，但是去掉了cc2的一些东西（因为cc的版本不一致）。

java安全入门（二）（cc链2）

CC1链在实际利用过程存在一些限制，例如jdk8u71版本已经无法利用反序列化漏洞了，通过分析发现jdk8u71版本中改写了sun.reflect.annotation.AnnotationInvocationHandler类的readObject方法，CC1链在jdk8u71版本以上已经被修复了，因此jdk8u71版本重新构造了一条新的利用链（CC2链）

不过CC2链使用了apache commons collections组件4.0版本来进行构造，并没有使用3.1版本，首先 CommonsCollections3 中无法使用，因为其 TransformingComparator 无法序列化。其次只有 CommonsCollections4-4.0 可以使用，因为 CommonsCollections4 其他版本去掉了 InvokerTransformer 的 Serializable 继承，导致无法序列化。

java_cc链1

组件介绍

Apache Commons 当中有⼀个组件叫做 Apache Commons Collections ，主要封装了Java 的 Collection(集合) 相关类对象，它提供了很多强有⼒的数据结构类型并且实现了各种集合工具类。

作为Apache开源项⽬的重要组件，Commons Collections被⼴泛应⽤于各种Java应⽤的开发，⽽正 是因为在⼤量web应⽤程序中这些类的实现以及⽅法的调⽤，导致了反序列化漏洞的普遍性和严重性。

java类加载机制

在Java的世界里，每一个类或者接口，在经历编译器后，都会生成一个个.class文件。

类加载机制指的是将这些.class文件中的二进制数据读入到内存中，并对数据进行校验，解析和初始化。最终，每一个类都会在方法区保存一份它的元数据，在堆中创建一个与之对应的Class对象。

java动态代理

为什么要使用动态代理？

在设计模式中有一个非常常用的模式：代理模式。学术一些来讲，就是为某些对象的某种行为提供一个代理对象，并由代理对象完全控制该行为的实际执行。