자바 직렬화의 대안을 찾으라

직렬화의 문제점

직렬화의 근본적인 문제는 공격 범위가 너무 넓고 지속적으로 더 넓어져 방어하기 어렵다는 점이다. ObjectInputStream의 readObject 메서드를 호출하면서 객체 그래프가 역직렬화되기 때문이다. readObject 메서드는 Serializable 인터페이스를 구현했다면 클래스패스 안의 거의 모든 타입의 객체를 만들어낼 수 있는 생성자다. 바이트 스트림을 역직렬화하는 과정에서 이 메서드는 그 타입들 안의 모든 코드를 수행할 수 있다. 이 말인즉슨, 그 타입들의 코드 전체가 공격 범위에 들어간다는 뜻이다.

자바의 표준 라이브러리나 아파치 커먼즈 컬렉션 같은 서드파티 라이브러리는 물론 애플리케이션 자신의 클래스들도 공격 범위에 포함된다. 관련한 모든 모범 사례를 따르고 모든 직렬화 가능 클래스들을 공격에 대비하도록 작성한다 해도, 애플리케이션은 여전히 취약할 수 있다.

자바 직렬화를 피하자

바이트 스트림을 역직렬화하는 일 자체가 스스로를 공격에 노출하는 행위다. 따라서 직렬화 위험을 회피하는 가장 좋은 방법은 아무것도 역직렬화하지 않는 것이다.
새로운 시스템에서 자바 직렬화를 써야 할 이유는 전혀 없다. 객체와 바이트 시퀀스를 변환해주는 다른 메커니즘이 많이 있다. 이 방식들은 자바 직렬화의 여러 위험을 회피하면서 다양한 플랫폼 지원, 우수한 성능, 풍부한 지원 도구, 활발한 커뮤니티와 전문가 집단 등 수많은 이점까지 제공한다.

직렬화 시스템(크로스-플랫폼 구조화된 데이터 표현)

자바 직렬화보다 훨씬 간단하다. 임의 객체 그래프를 자동으로 직렬화/역직렬화하지 않는다. 대신 속성-값 쌍의 집합으로 구성된 간단하고 구조화된 데이터 객체를 사용한다. 그리고 기본 타입 몇 개와 배열 타입만 지원할 뿐이다. 이런 간단한 추상화만으로도 아주 강력한 분산 시스템을 구축하기에 충분하고, 자바 직렬화가 가져온 심각한 문제들을 회피할 수 있음이 밝혀졌다.

JSON

• 자바스크립트용으로 만들어졌다.
• 브라우저와 서버의 통신용으로 설계됐다.
• 텍스트 기반이라 사람이 읽을 수 있다.
• 데이터를 표현하는데만 쓰인다.

프로토콜 버퍼

• C++용으로 만들어졌다.
• 구글이 서버 사이에 데이터를 교환하고 저장하기 위해 설계했다.
• 이진 표현이라 효율이 높다. 사람이 읽을 수 있는 텍스트 표현도 지원한다.
• 문서를 위한 스키마(타입)를 제공하고 올바로 쓰도록 강요한다.

객체 역직렬화 필터링

신뢰할 수 없는 데이터는 역직렬화하지 말자. 역직렬화한 데이터가 안전한지 확신할 수 없다면 객체 역직렬화 필터링(java.io.ObjectInputFilter)을 사용하자. 자바 9에 추가되었고, 이전 버전에서도 쓸 수 있도록 이식되었다.
객체 역직렬화 필터링은 데이터 스트림이 역직렬화되기 전에 필터를 설치하는 기능이다. 클래스 단위로, 특정 클래스를 받아들이거나 거부할 수 있다. ‘기본 수용’ 모드에서는 블랙리스트에 기록된 잠재적으로 위험한 클래스들을 거부한다. 반대로 ‘기본 거부’ 모드에서는 화이트리스트에 기록된 안전하다고 알려진 클래스들만 수용한다. 블랙리스트 방식보다는 화이트리스트 방식이 낫다. 애플리케이션을 위한 화이트리스트를 자동으로 생성해주는 SWAT(Serial Whitelist Application Trainer)이라는 도구도 있다.
필터링 기능은 메모리를 과하게 사용하거나 객체 그래프가 너무 깊어지는 사태로부터도 보호해준다. 하지만 직렬화 폭탄은 걸러내지 못한다.

직렬화는 위험하니 피해야 한다. 시스템 밑바닥부터 설계한다면 JSON이나 프로토콜 버퍼 같은 대안을 사용하자. 클래스가 직렬화를 지원하도록 만들지 말고, 꼭 그렇게 만들어야 한다면 정말 신경써서 작성해야 한다.