□ AntiXss 라이브러리 실제 적용 사례
실제 적용사례를 설명 할 웹사이트는 앞서 살펴본 AntiXSS 라이브러리 적용 예시와 동일한 개발환경에서 실제로 운영되고 있는 웹사이트이고, 접속자들에게 에디터환경의 글쓰기 기능을 제공합니다. 그리고 게시판에는 nhn社에서 무료로 제공하는 네이버 스마트에디터가 적용되어 있습니다[1].
XSS공격을 차단하기 위해 가장 좋은 방법은 단순 문자열만 입력받아 허용 문자열만 받아들이거나 위험한 문자열을 제거하는 것이지만, 실제 웹사이트 운영환경은 접속자들에게 더욱 더 많은 문서작성 기능을 제공해야 하고 최근의 웹사이트들의 동향을 보더라도 HTML 태그 편집 기능정도는 기본으로 제공하고 있습니다.
그러므로 지금부터 살펴 볼 웹사이트는 허용할 HTML태그를 목록으로 관리하면서 허용 목록이외에는 제거하거나 인코딩하기 때문에, 결과적으로 에디터에서 제공하지 않는 HTML 태그나 악성 스크립트 실행이 가능한 문자열들이 제거되는 Positive(또는 White list) 방식으로 입력값을 검증합니다. 좀 복잡하긴 하지만 사례를 설명하기에는 좋은 방법이라고 생각합니다.
실제로, 웹사이트 운영을 위해서는 다양한 정책설정이 필요하며, 그 중 하나가 사용자 입력값에 대한 검증을 입력받을 때 하는 경우와 화면 출력시에 검증하는 경우가 있으므로, 운영환경에 따라 결정하고 반영해야 합니다.
일반적인 경우는 게시판 게시물 출력과 같은 사용자 입력값 출력 시에 검증하고 걸러내는 방식이 권장되지만, 본 문서와 예시에서는 입력값을 받을 때에 검증하는 방식으로 설명하였으므로, 실제 적용을 위해서는 입력값 검증방식의 정책결정에 대한 고려가 반드시 필요합니다. 물론 입력단계와 출력단계 모두 적용하는 방법도 가능합니다.
그럼 실제 글쓰기 실행을 통해 어떻게 동작하는지 확인 해 보겠습니다. 아래의 화면은 게시판에
“태그 사용법이 궁금해요”
라는 부분이 어떻게 입력되어 DB에 저장되는지 알아봅니다. 참고로, 스마트에디터의 다양한 기능 중 사용빈도가 적고 관리에 어려움이 있는 기능들은 제거한 상태입니다.
이렇게 글쓰기를 시도하면 에디터에서는 “” 라는 부분이 태그로 인식되어 화면에 표시되지 않는 문제가 발생하지 않도록 스마트에디터가 사용자가 입력한 부분을 인코딩합니다. 그러므로 서버측에 전달되는 문자열은 위의 그림과 같습니다.
이제 서버측에서는 전달받은 문자열에 대한 검증절차가 시작됩니다.
- 태그식별자(<,>)에 검증대상 임의의 문자 표식(##@@@) 추가
서버측에서는 전달받은 문자열 중 검증이 필요한 태그를 식별할 수 있는 식별자를 추가하여 검증대상으로 표시 해 둡니다.
그 결과 사용자가 입력한 결과는 아래와 같이 변수 내에서 변경됩니다.
- 모든 입력값에 HTML Encoding 적용
추후에 HTML태그로 다시 환원 할 태그에 표시를 해 두었으므로, 이제 모든 입력문자열을 HTML Encoding 처리 하며, 해당 소스코드 예시와 HTML Encoding 처리 후의 변경된 문자열은 아래과 같습니다.
- 허용 태그 목록과 비교하여 HTML 태그 환원 처리
Encoding 문자열 중 태그식별자와 일치하는 문자열을 허용 대상 태그목록과 비교하여 허용하는 HTML태그인 경우엔 원래의 태그문자로 환원합니다. 해당 소스코드는 아래와 같으며, 허용 목록 리스트는 일부만 표시하였습니다.
허용하는 HTML태그에 대한 처리가 끝나면 아래와 같이 DB에 입력 될 문자열이 완성됩니다.
- HTML 태그 식별자 제거
태그식별자로 사용했던 문자열을 제거하여 입력값 검증 절차를 마무리 하고, DB에 게시물을 추가합니다.
그러므로 게시물 열람 시의 브라우저에는 게시글 등록자가 입력한 문자열과 동일하게 표시되며, 만약 허용 태그 이외의 입력값에 대해서는 Decoding 하지 않으므로, 실행 가능한 HTML태그나 스크립트가 아니라 단순 문자열(Literal)로만 표시되므로 안전하게 게시판을 운영 할 수 있습니다.
마지막으로 본 예시의 도입부에 설명 한 바와 같이 사용자 입력값을 받는 단계에서 검증한 방식입니다. 사용자 입력값 검증절차를 출력 시에 적용을 하는 경우에도 Positive(또는 White list) 방식으로 출력값을 검증한다면 허용하는 태그목록이나 스크립트만 출력되므로 본 문서에서 제시한 방법보다 수월할 수 있습니다.
다만, 입력값검증을 전송받는 단계에서 수행하는 경우에는, 예를 들어 글쓰기 하는 경우에만 검증절차가 수행되어 부하가 발생하고 다소 처리시간이 소요되어도 글 작성 시에만 영향을 미치지만, 만약 출력할 때 검증한다면 허용목록 적용방법이나 일관된 정책 관리가 수월한 반면에 접속자에게 전송되는 페이지를 생성할 때마다 부하가 가중될 수 있는 단점이 있으므로, 운영환경을 반드시 고려하여 결정해야 합니다.
다음에는 OWASP에서 진행하고 있는 Enterprise Security AP(ESAPI)에 대해서도 소개 해 드리겠습니다[2].
------------------------------------------------------
[1]http://inside.naver.com/smarteditor
[2]http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API