이 문서 내용은 좀 낡았습니다.
60일이나 편집 안된 오래된 망한 문서니 개발 문서인 경우 참고할 때 조심하세요. 최신 정보를 알고 싶으면 게시판에 글 써주세요

목차

1. 개요
2. 서론
3. 그 전에
4. 방어적 프로그래밍
5. 왜 어려운가?
6. 해결 방법은 없는가?
7. 결국

1. 개요 ✎ ⊖

방어적 프로그래밍에 대해서 생각은 하면서 왜 잘 안되는가에 대해서 고민해보는 문서

2. 서론 ✎ ⊖

오픈나무는 심심하면 XSS escape를 빼먹어서 귀찮게 공지를 써야하는 상황이 발생한다

오늘도 공지를 쓰면서 이에 대해서 반성해보는 내용이다

3. 그 전에 ✎ ⊖

그나마 다행인 점은 오픈나무는 세션 쿠키에 HttpOnly 옵션을 기본으로 사용한다

그리고 자동 로그인을 지원하지 않기 때문에 XSS 사건이 터져도 특정 사이트나 혐짤을 띄우는 것 말곤 공격자가 할 수 있는 일이 없다

근데 그건 그냥 위키 내용에 써도 테러 가능한 부분이니 사실상 할 수 있는 건 없다고 파악된다

그래서 최소한의 보안 조치는 이미 되어있기 때문에 보안 리포트라기 보단 그냥 이 문서는 한탄하는 문서다

4. 방어적 프로그래밍 ✎ ⊖

방어적 프로그래밍은 말하는 사람마다 엄밀한 정의가 전부 다르긴 하지만 일반적으로 예상하지 못한 입력에 대응하는 방법을 생각하면서 프로그래밍 하는 것이다

5. 왜 어려운가? ✎ ⊖

예상하지 못한 입력은 개발자도 사실 예상하기 어렵다 사실 코드를 다 작성하고 한번 더 코드 리뷰를 똑바로 해봐야 하는데... 그게 잘 안된다

결국 이 문제는 습관의 문제이기 때문에 그래서 더 어려운 것 같다

6. 해결 방법은 없는가? ✎ ⊖

  • 테스트 케이스를 제대로 작성하고 그 테스트 케이스에 따라서 동작을 테스트 한다
이게 가장 현실적인 방법인데 문제는 테스트 케이스 고려할 때부터 예상하지 못한 입력을 빼먹으면 그건 또 뚫린다
  • TDD 방법론을 사용한다
이게 사실 가장 이상적인 방법이지만 오픈나무에 적용하기엔 개발 생산성을 너무 박살내버린다
  • 사용자가 입력할 수 있는 여지를 줄인다
문제는 위키 특성상 이건 안된다
  • 2중으로 안전을 보장할 수 있는 장치를 만든다
위에서 말한 HttpOnly가 이미 그 역할을 잘 하고 있다

7. 결국 ✎ ⊖

디시인사이드 같은 초대형 사이트도 그게 잘 안되서 맨날 털리는 걸 보면 이건 참 어려운 문제인 것 같다

가장 현실적인 방법은 테스트 케이스를 제대로 작성해서 테스트를 해야할 것 같다