<이펙티브 자바> 12. 직렬화

85. 자바직렬화의 대안을 찾아보자

• 직렬화란 자바가 객체를 바이트 스트림으로 인코딩 하는 과정이다
• 근본적인 문제는 공격범위가 너무 넓고 지속적으로 넓어져서 방어하기 어렵
  • readObject 메서드는 모든 타임의 객체를 만들어 낼수있음
• 가젯 : 역직렬화 과정에서 호출되어 잠재적으로 위함한 동작을 수행하는 메서드
• 역직렬화 시간이 오래걸리는 짧은 스트림은 디도스 공격에 취약
• 직렬화 위험을 피하는 가장좋은 방법은 사용하지 않는 것이다
• 신뢰할수없는 데이터는 절대 역질렬화하지 않는다
• 꼭 써야한다면 자바9에 추가된 ObjectInputFilter를 사용하자
  • 블랙리스트 방식보다는 화이트리스트 방식을 사용하자
• JSON이나 프로토콜 버터 같은 대안을 사용하자

 

86. Serializable을 구현하지는 신중히 결정하라

• Serializable 을 구현하면 릴리스 한뒤에는 수정하기 어렵다
  • 기본 직렬화 형태에서는 클래스의 private, package-private 인스턴스들 마저 API로 공개되는게 되버린다
  • 모든 직렬화된 클래스는 고유 식별 번호를 부여 받는다 serialVersionUID
    • 자동 생성되는 값에 의존하면 쉽게 호환성이 깨져버려 런타임에 InvalidClassException이 발생할 것이다.
• 버그와 보안 구멍이 생길 위험이 높아진다
  • 숨은 생성자로 역직렬화 되어 기본 메커니즘인 생성자로 구축되어 불변식을 보장하고 내부를 들여다볼수없게 하는 부분이 지켜지지않는다.
• 해당클래스의 신버전을 릴리즈 할때 테스트 할 것이 늘어난다
• 상속용으로 설계된 클래스는 대부분 Serializable을 구현하면 안되고 인터페이스 대부분 Serializable을 확장해서는 안된다.

 

87. 커스텀 직렬화 형태를 고려해 보자

• 객체의 물리적 표현과 논리적 내용이 같다면 기본 직렬화 형태라도 무방하다
• 불변식 보장과 보안을 위해 readObject 메서드를 제공해야 할 때가 많다
• 객체의 물리적 표현과 논리적 표현의 차이가 클때 기본직렬화 형태 사용하면 크게 네가지 면에서 문제가 생긴다
  • 현재의 내부표현방식에 묶여버린다
  • 공간을 차지할수있다
  • 시간이 많이 걸릴수있다
  • SOF를 일의킬수 있다

 

88. readObject 메서드는 방어적으로 작성하라

• 역직렬화 시 클라이언트가 소유해서는 안되는 객체 참조 를 갖는 필드를 모두 방어적으로 복사해야한다.

 

89. 인스턴스 수를 통제해야한다면 readResolve 보다는 열거타입을 사용하자

• serializable을 추가하는 순간 더이상 싱글턴이 아니게 된다
• 인스턴스 통제 목적으로 사용하려면 transient로 선언해야한다

 

90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라

• 바깥클래스의 논리 상태를 정밀하게 표현하는 중첩클래스를 설계해 private static으로 선언한다.
  • 중첩클래스의 생성자는 단하나
  • 바깥클래스를 매개변수로 받아야한다.