아이템 50. 적시에 방어적 복사본을 만들라

item 50 : 적시에 방어적 복사본을 만들라

자바는 안전한 언어
- 네이티브 메서드를 사용하지 않으니 C, C++에서 흔히 보는 버퍼 오버런, 배열 오버런, 와일드 포인터 같은 메모리 관련 오류에서 안전
- 하지만, 다른 클래스로부터의 침범을 아무런 노력없이 막을 수 있는건 아니다!
- 방어적으로 프로그래밍을 해야한다.
- 악의적인 의도를 가진 사람들이 시스템의 보안을 뚫을려는 시도

Period Sample

public final class Period {
private final Date start;
private final Date end;

public Period(Date start, Date end) {
    if (start.compareTo(end) > 0) {
        throw new IllegalArgumentException(start + " after " + end);
    }

    this.start = start;
    this.end = end;
}

public Date start() {
    return start;
}

public Date end() {
    return end;
}

public void print() {
    System.out.println("start : " + start);
    System.out.println("end : " + end);
}
}

Period 인스턴스의 내부를 공격해보자
- end의 setYear를 통해서 p의 내부 end의 값도 변경이 되어버린 상황
- java8에서는 Date 대신 불변 Instant를 사용하면 된다. (LocalDateTime, ZoneDateTime)
- Date는 새로운 코드를 작성할 때는 더 이상 사용하지 말것.
- 오래된 Date라 내부 구현에 잔재가 남아있을 가능성이 높다.
- 내부를 보호하려면!
- 생성자에서 받은 가변 매개변수 각각을 방어적으로 복사(defensive copy) 해야한다.
수정한 생성자 - 매개변수의 방어적 복사본을 만든다.
- ```
public Period(Date start, Date end) {
// Old version
//  if (start.compareTo(end) > 0) {
//      throw new IllegalArgumentException(start + " after " + end);
//  }
//  this.start = start;
//  this.end = end;

this.start = new Date(start.getTime());
this.end = new Date(end.getTime());

if (this.start.compareTo(this.end) > 0) {
    throw new IllegalArgumentException(this.start + " after " + this.end);
}
}
```
- 실행 결과
- 주목 : 매개변수의 유효성 검사(Item 49)를 하기 전에 방어적 복사본을 만들고, 이 복사본으로 유효성을 검사
- 멀티스레딩 환경이라면 원본 객체의 유효성을 검사한 후 복사본을 만드는 그 찰나의 취약한 순간에 다른 스레드가 원복 객체를 수정할 위험성이 존재
- 검사시점/사용시점(time-of-check/time-of-use) 공격 혹은 TOCTOU
- 방어적 복사에 Date의 clone을 사용하지 않았다.
- clone이 악의를 가진 하위 클래스의 인스턴스를 반환할 가능성이 있음
- 매개변수가 제 3자에 의해 확장될 수 있는 타입이라면 방어적 복사본을 만들 때 clone을 사용하지 말것.

Period 인스턴스를 향한 두번째 공격

가변 필드의 방어적 복사본을 반환하는 것으로 해결 가능


public Date start() {
return new Date(start.getTime());
}

public Date end() { return new Date(end.getTime()); }


- 매개변수 유효성 체크를 해서 시작 시각이 종료 시각보다 나중일 수가 없고,
- `Period` 자신 말고는 가별 필드에 접근할 방법이 없으니 확실
- 모든 필드가 객체 안에 완벽하게 캡슐화!

매개변수를 방어적으로 복사하는 목적
- 메서드든 생성자든 틀라이언트가 제공한 객체의 참조를 내부의 자료구조에 보관해야 할 때면 그 객체가 잠재적으로 변경될 수 있는지 생각!
- 임의로 변경되어도 그 클래스가 문제없이 동작할지를 따질 것
- 확신이 안된다면 복사본을 만들어 저장할 것
- 내부 객체를 클라이언트에 건네주기 전에 방어적 복사본을 만드는 이유도 동일
주의 : 방어적 복사에는 성능 저하가 따르고, 또 항상 쓸 수 있는 것도 아니다.

핵심 정리

클라이언트로부터 받거나, 반환하는 구성요소가 가변이라면 방어적으로 복사

복사 비용이 너무 크거나, 클라이언트가 그 요소를 잘못 수정할 일이 없음을 신뢰한다면

방어적 복사를 수행하는 대신 수정했을 때의 책임이 클라이언트에 있음을 문서에 명시!

NMP-Study / EffectiveJava2022

아이템 50. 적시에 방어적 복사본을 만들라 #50

item 50 : 적시에 방어적 복사본을 만들라