• 자바의 역직렬화는 명백하고 현존하는 위험이다. 이 기술은 지금도 애플리케이션에서 직 접 혹은, 자바 하부 시스템(RMI(Remote Method Invocation), JMX(Java Management Extension), JMS(Java Messaging System) 같은)을 통해 간접적으로 쓰이고 있기 때문 이다. 신뢰할 수 없는 스트림을 역직렬화하면 원격 코드 실행(remote code execution, RCE), 서비스 거부(denial-of-service, DoS) 등의 공격으로 이어질 수 있다. 잘못한 게 아 무것도 없는 애플리케이션이라도 이런 공격에 취약해질 수 있다

static byte[] bomb() {
    Set<Object> root = new HashSet<>(); 
    Set<Object> s1 = root;
    Set<Object> s2 = new HashSet<>(); 
    for (int i = 0; i < 100; i++) {
        Set<Object> t1 = new HashSet<>(); 
        Set<Object> t2 = new HashSet<>(); 
        t1.add("foo"); // t1을 t2와 다르게 만든다. 
        s1.add(t1); s1.add(t2);
        s2.add(t1); s2.add(t2); s1 = t1;
        s2 = t2;
    }
    return serialize(root); // 간결하게 하기 위해 이 메서드의 코드는 생략함 
}

1 이 객체 그래프는 201개의 HashSet 인스턴스로 구성되며, 그 각각은 3개 이 하의 객체 참조를 갖는다. 2 문제는 HashSet 인스턴스 를 역직렬화하려면 그 원소들의 해시코드를 계산해야 한다는 데 있다. 3 루트 HashSet에 담긴 두 원소는 각각 (루트와 마찬가지로) 다른 HashSet 2개씩을 원 소로 갖는 HashSet이다. 4 그리고 반복문에 의해 이 구조가 깊이 100단계까지 만 들어진다. 따라서 이 HashSet을 역직렬화하려면 hashCode 메서드를 2^100번 넘게 호출해야 한다.

• 역직렬화가 영원히 계속된다는 것도 문제지만, 무언가 잘못되 었다는 신호조차 주지 않는다는 것도 큰 문제다.
• 이 코드는 단 몇 개의 객체만 생성해도 스택 깊이 제한에 걸려버린다. 이 객체 그래프는 201개의 HashSet 인스턴스로 구성되며, 그 각각은 3개 이 하의 객체 참조를 갖는다.

• 객체와 바이트 시퀀스를 변환해주는 다른 메커니즘이 많이 있다. 이 방식들은 자바 직렬화의 여러 위험을 회피하면서 다양한 플랫폼 지원, 우수한 성능, 풍 부한 지원 도구, 활발한 커뮤니티와 전문가 집단 등 수많은 이점까지 제공한다.
• 이 책에서는 자 바 직렬화와 구분하고자 크로스-플랫폼 구조화된 데이터 표현(cross-platform structured-data representation)이라 한다.

직렬화는 위험하니 피해야 한다.
시스템을 밑바닥부터 설계한다면 JSON이나 프로토콜 버퍼 같은 대안을 사용하자.
신뢰할 수 없는 데이터는 역직렬화하지 말자.
꼭 해야 한다 면 객체 역직렬화 필터링을 사용하되, 이마저도 모든 공격을 막아줄 수는 없음을 기억하자.
클래스가 직렬화를 지원하도록 만들지 말고, 꼭 그렇게 만들어야 한다면 정말 신경 써서 작성해야 한다.