 |
|
파일 업로드
웹 애플리케이션에 파일을 업로드할 수 있게 하는 것은 매우 조심스러운 일이다. 누구나 무슨 파일이든 업로드할 수 있고 직접적인 웹 요청을 통해 파일에 접근할 수 있다면 아무리 조심을 한다고 해도 위험한 일임에는 틀림없다. 최소한 애플리케이션을 방문하는 이들에게 악의적인 코드를 퍼뜨릴 수도 있고 최악의 경우 서버에서 임의의 코드가 실행될 수 있기 때문이다.
본 튜토리얼에서 설명하는 접근법은 완벽하지 못하다. 이 문제는 여기뿐 아니라 Part 3에서도 더 다루겠다.
무엇이 문제인가?
문제를 위한 기본 접근 방법을 생각해보자. 어떤 사용자든 크리키에 파일을 업로드할 수 있다고 가정하자. 생각 없이 누구든 간단히 app/webroot에 uploads 같은 디렉터리를 만들고 업로드로 제출한 파일을 이 디렉터리에 덤프해 http://localhost/uploads를 통해 그 파일들에 접근할 수 있다고 하자. 무척 빠르고 쉽다. 하지만 이는 무서운 결과를 초래할 수 있다.
사용자가 업로드하는 파일이 알려지지 않은 새로운 악성 자바스크립트를 포함하고 있다고 가정하자. 이는 세션이나 쿠키 데이터를 훔칠 수도 있고 더 심한 경우는 사용자 정보를 바꿔버릴 수도 있다. 더구나 이 스크립트가 웹 서버에 존재하게 된다.
여기에 같은 사용자가 자바스크립트를 불러내는 HTML 파일을 업로드한다고 가정하면 더 무서운 일이 벌어진다. 누구든 페이지를 보는 사용자는 자신의 쿠키를 노출시키게 되고, 이유도 모르는 채 악성 코드에 감염되어 버린다. 누구든 크리키에서 이런 경험을 하고 싶진 않을 것이다.
더 심각한 상황은 phpinfo(): <?php phpinfo(); ?>을 실행하는 유효 코드를 포함하는 info.php 파일을 사용자가 업로드했을 때다.
이러한 일은 의도적인 악의가 없더라도 끔직할 정도로 간단하게 벌어진다. 누구든 http://localhost/uploads/info.php에 접속하여 스크립트를 실행할 수 있다. 진짜 악의적인 사용자가 직접 우리 서버에 무엇을 작성하고 업로드하고 실행할지 상상해 보자. 그리고 이것이 어떤 결과를 초래할지 상상해 보자.
그럼 무엇을 해야 하는가?
아주 훌륭한 질문이다. 이번 글과 해결책을 제시할 Part 3에서 생각해 볼 문제다. 다음과 같은 사항을 고려해볼 수 있다.
- 사용자가 업로드하는 파일은 다른 사용자들도 접근할 수 있어야 한다.
- 어떤 부분에 있어서는 새 위키 마크업을 통해 사용자들이 엔트리에 이미지를 추가할 수 있도록 해야 한다.
- 어떤 경우에도 서버에 올라간 파일이 원격 사용자에 의해 실행되는 것을 막는다.
- 어떤 파일 타입을 업로드할 것인지 제어할 수 있는 메커니즘이 있어야 한다.
- 어떤 해결책이든 성능과 보안의 균형이 맞아야 한다.
이 문제를 해결할 수 있는 방법은 많다. 하지만 결점이 없는 방법은 없다. 무엇을 할 수 있는지 알아보자.
간격 메우기
지금까지 많은 것을 배웠다. 위키의 기본 구조 코드를 가지고 있지만 앞으로 더 배워야 할 것도 많다. 특히 다음을 기억하자.
- 로그인하지 않은 사용자가 엔트리를 편집하면 오프셋 에러가 뷰 페이지에 뜬다. 사용자 이름을 모르기 때문이다. 사용자 이름을 모르면 IP 주소가 대신 보이게 고치자.
- 위키 마크업을 해석할 수 있는 코드는 다음과 같이 사용될 수 있다.
- 로(raw) HTML을 내용 상자에 넣어보자. 무슨 일이 벌어질 것인가? 이를 어떻게 고칠 것인가? 어떤 다른 부정 테스트를 식별할 수 있을까?
- 중첩된 마크업으로 실험을 하고 이를 나눌 수 있는지 알아보자.
- 위키 마크업 해석 코드를 정리한다. 여러 가지 방법으로 쉽게 줄일 수 있을 것이다.
-
EntryRevisions 컨트롤러의 뷰 동작은 엔트리 컨트롤러의 뷰 동작과 똑같아야 한다. 하지만 엉망인 위키 마크업 해석 코드를 복사하는 대신에 코드가 줄어들기를 기다렸다가 복사해 덮는다.
- 파일 업로드 문제를 잊지 말고 잘 생각하자.
지금까지의 정보로도 크리키의 사용자와 권한을 다루는 Part 3에 이르기 전까지 코딩하는 데 무리가 없을 것이다. 그 때까지 즐겁게 코딩하기 바란다.
| 
