이 글은 MS SRD 블로그의 MSHTML Host Security FAQ: Part I of II를 번역한 것입니다.

MSHTML은 인터넷 익스플로러의 렌더링 엔진입니다. MSHTML은 웹 브라우저에서 사용될 뿐 아니라, 일반적인 응용 프로그램의 UI에서 HTML을 렌더링할 때도 사용됩니다. 대부분의 사람들은 MSHTML이 얼마나 여러 군데에서 사용되고 있는지 잘 모를 겁니다. 예를 들자면, XP 제어판의 프로그램 추가/제거가 MSHTML을 이용해서 구현되어 있습니다. 이렇게 MSHTML 렌더링 엔진을 호스팅할 때에는 반드시 보안에 주의를 기울여야 합니다. 이번 FAQ는 MSHTML을 호스팅할 때 자주 발생하는 실수들을 다루겠습니다.

MSHTML은 직접 호스팅할 수도 있고, SHDOCVW를 이용해서 호스팅할 수도 있습니다. 별다른 언급이 없다면 이 FAQ에 나오는 정보는 양쪽 다 적용되는 것으로 간주하시면 됩니다.

각 MSHTML 호스팅 시나리오 별로 어느 정도의 위험이 존재하나요?

위험 수준 3: 정적인 내용을 출력하는 경우

로컬 리소스(리소스 파일, 로컬 드라이브의 HTML 파일 등)에서 불러온 정적인 내용을 바로 출력하는 경우는 위험이 별로 없습니다. 아예 없다고는 말할 수 없습니다. 가령 공격자가 기존에 등록된 프로토콜 핸들러를 이용하여 명령줄 매개변수를 전달하는 방식으로 공격하는 경우를 상정해 볼 수 있습니다.

위험 수준 2: 제한된 내용을 출력하는 경우

특정 웹사이트로 MSHTML 인스턴스를 고정시켜 둘 수 있습니다. 그렇지만 SSL을 이용하지 않는다면 MITM이나 DNS 포이즈닝 공격을 받을 수 있으며, 그 결과로 호스팅하고 있는 MSHTML 인스턴스에서 임의의 스크립트가 실행될 수 있습니다.

SSL을 사용하는 경우라고 하더라도 (인증서 검증도 통과했더라도) 그 사이트에서 렌더링하는 내용이 무조건 안전하다고 말할 수는 없습니다. 아무리 출처가 안전하다고 하더라도 사용자의 컴퓨터에서 임의의 코드를 자동으로 실행하도록 허가해서는 안 됩니다. 이는 최소 권한의 원칙입니다.

내용을 어디에서 받았느냐에 관계없이, 이런 식으로 안전하게 실행해야만 이후에 취약점이 발생하더라도 그 여파를 최소화 할 수 있게 됩니다.

위험 수준 1: 임의의 내용을 출력하는 경우

이 경우에 MSHTML 호스트 프로그램은 인터넷 익스플로러 내부에서 적용되는 것과 동일한 수준의 보안을 적용한 상태에서 어떠한 바로 가기라도 받아들여선 안 됩니다. 그렇지 않으면 인터넷 익스플로러에서는 가능하지 않을 공격이 MSHTML 호스트 프로그램에서는 먹힐 수 있습니다.

위험을 최소화 하는 한 가지 방안은 MSHTML 호스트의 내부 영역으로만 이동할 수 있도록 하는 것입니다. 가령 비주얼 스튜디오가 MSHTML을 사용하긴 하지만 이를 이용해서 웹 사이트로 이동하는 것은 별로 흔한 일이 아닙니다. 비주얼 스튜디오 MSHTML 호스트가 취약점을 가지고 있더라도 실제로 공격하기가 그리 쉽지는 않을 것입니다. 동시에 비주얼 스튜디오의 MSHTML 인스턴스가 웹 컨텐츠에 들어있는 임의의 코드를 실행하거나, 로컬 파일을 읽을 수 없도록 하는 것은 당연한 일이겠죠.

위험 수준 0: 이메일이나 웹에서 받은 임의의 내용을 클릭도 없이 출력하는 경우

예를 들어, 미디어 플레이어가 MSHTML을 호스팅하면서 임의의 주소로 이동할 수 있도록 허용한다고 해봅시다. 브라우저에서는 보안 때문에 막혔을 것들이 위의 미디어 플레이어 호스팅 시나리오에서는 그냥 회피할 수 있게 됩니다. (미디어 파일이 미디어 플레이어의 HTML 인스턴스로 하여금 임의의 웹 사이트로 이동하도록 만들 수 있습니다.) 웹 브라우저를 공격 경로로 사용하는 경우가 많기 때문에, 이런 시나리오는 반드시 피해야 합니다.

호스팅 환경에서 안전하게 HTML에 고급 기능을 지원하려면 어떻게 해야 하나요?

MSHTML 인스턴스를 호스팅하는 환경에서 실행되는 내용에 특별한 기능을 부여해야 하는 경우가 자주 있습니다. 이 부분은 FAQ 2부에서 다룰 가이드라인을 주의해서 따르시고, 절대로 귀찮다고 MSHTML 인스턴스가 안전하지 않은 행동(임의의 시스템 명령 실행 등)을 수행할 수 있는 권한을 다 열어주시면 안 됩니다.

흔히 사용되는 MSHTML 확장 기법은 아래와 같습니다:

• window.external
  window.external을 이용해서 DOM을 확장할 수 있습니다. 한 가지 예는 MSHTML을 이용해서 사용자 인터페이스를 출력하는 CD 굽기 프로그램입니다. 이 응용 프로그램은 window.external로 BurnToCD() 메소드를 노출함으로써 CD 굽기 기능을 사용자 인터페이스에서 실행할 수 있도록 만들었습니다. window.external 확장 메커니즘에 대해서는 http://support.microsoft.com/kb/188015를 참고하시기 바랍니다. 위에서 언급한 일반적인 보안 가이드라인을 여기서도 준수해야 합니다.
• ActiveX
  ActiveX 컨트롤이 특정 MSHTML 환경에서만 동작하도록 만들 수 있습니다. 예를 들어 HTML Help는 HH.EXE에서 호스팅되는 경우에만 기능을 제공하도록 구현되어 있습니다. 여러분이 유사한 솔루션을 구현하신다면, 여러분의 MSHTML 호스트에서만 기능을 제공하도록 구현하십시오. 호스팅하고 있는 프로세스의 이름을 검사하는 것이 한 가지 방법입니다. 이런 식으로 여러분의 기능이 의도하지 않게 다른 응용 프로그램에서 사용되는 것을 방지할 수 있습니다.
  
  ActiveX 컨트롤이 호스팅 페이지의 URL을 식별할 수 없는 경우도 있습니다. (MS06-04에서 수정된 취약점을 공격하는 코드가 이런 경우를 이용했습니다.) 그러므로 컨트롤을 개발하실 때 호스팅 환경을 식별할 수 없는 경우에는 안전한 상태로 돌아가도록 구현하시기 바랍니다. ActiveX 컨트롤용 SiteLock 템플릿을 사용하시면 이런 류의 위협을 방지할 수 있습니다.
• 템플릿
  HTML 템플릿 파일을 읽어들이고 다른 곳에서 정보를 끌어와서 템플릿을 채운 다음, MSHTML이 렌더링하도록 만드는 응용 프로그램이 많습니다. MP3 파일에서 메타데이터를 추출한 다음에, 이 메타데이터를 템플릿에 집어넣어 MSHTML로 표시하는 미디어 미리 보기 프로그램이 대표적인 예입니다. 여러분이 이런 방식을 사용한다면 인젝션 취약점을 주의하시기 바랍니다. MSHTML 호스트에 스크립트나 HTML, ActiveX 컨트롤이 주입되지 않도록 해야 합니다. Inspect your Gadget 문서를 참고하시기 바랍니다. 이런 유형의 문제에 대응하는 방법이 설명되어 있습니다. (비스타 사이드바 가젯에서 적용되는 가이드라인의 많은 부분은 템플릿에도 동일하게 적용할 수 있습니다.)

MSHTML 호스트가 IE 보안 영역에 적용되는 보안 정책을 그대로 적용하도록 하려면 어떻게 해야 하나요?

기본적으로 MSHTML은 렌더링하고 있는 페이지의 영역을 알아내서 보안 정책을 적용합니다. 이 때문에 인터넷 익스플로러 브라우저에서나 합당한 모델을 MSHTML 호스트에 적용하면서 문제가 자주 발생합니다.

뉴스 리더 응용 프로그램이 로컬 하드 드라이브로 HTML로 HTML을 다운로드한 다음 MSHTML 인스턴스로 다운 받은 HTML을 본다고 가정해봅시다. 인터넷을 통해 들어온 데이터가 로컬 컴퓨터 영역에서 렌더링됩니다. 로컬 컴퓨터 영역 안에서는 HTML이 안전하지 않은 기능에 접근할 권한이 생기고, 임의의 코드를 실행할 수 있게 됩니다. 브라우저에서는 로컬 컴퓨터 영역 잠금을 통해 위협을 완화할 수 있지만, 위에서 제시한 뉴스 리더 프로그램에는 기본값으로 적용되지 않습니다. Feature Control Key를 따로 설정해야만 적용 가능합니다. 응용 프로그램 호환성 때문에 로컬 컴퓨터 영역 잠금을 기본값으로 넣을 수 없었습니다.

위의 예제는 MSHTML 호스팅 환경 안에서 페이지가 렌더링 될 때 인터넷 익스플로러의 보안 영역에 적용되는 보안 정책을 이해하는게 왜 중요한지 보여줍니다.

보안 관리자 구현하기

대부분의 경우에는 기본으로 제공되는 인터넷 익스플로러의 보안 정책이 MSHTML 호스트 환경에도 잘 맞지만, 그렇지 않은 경우에는 직접 보안 관리자를 구현해야 합니다. 보안 관리자를 이용하면 인터넷 익스플로러의 고급 영역 옵션에서 사용할 수 있는 것보다 더 상세한 브라우저 정책을 적용할 수 있습니다.

예를 들어, 직접 구현한 보안 관리자는 모든 스크립트를 비활성화 하면서도 딱 하나의 특정한 ActiveX 컨트롤만 실행하도록 만들 수 있습니다. 보안 관리자에서 제어할 수 있는 정책 플래그는 URL Action이라 불리고 urlmon.h에 정의되어 있습니다. 여러분의 보안 관리자에서 스크립트나 ActiveX를 기본값으로 차단해놨다고 하더라도, 다른 URL Action을 더 비활성화해야 할 수 있습니다. 가령 여러분의 호스트에서 프레임과 액티브 컨텐트를 비활성화 해놓았더라도, URLACTION_HTML_META_REFRESH까지 비활성화하지 않으면 HTML을 이용해서 다른 페이지로 넘어가도록 만들 수 있습니다.

보안 관리자의 구현 여부와 관계 없이 Asynchronous Pluggable Protocol Handler (APP)를 구현하고 싶은 경우가 있을 겁니다. APP가 IInternetProtocolInfo를 구현하고 PARSE_SECURITY_URL과 PARSE_SECURITY_DOMAIN을 제공하는 방법으로 보안 영역에서 사용할 수 있는 URL을 제어할 수 있습니다.

APP를 구현한다면 가급적 시스템 전역적으로 등록하지 마세요. 여러분의 프로세스에서 동적으로 로드해서 사용하시기 바랍니다. 전역적으로 등록하는 경우 인터넷 익스플로러가 공격받을 여지를 남겨두게 될 수 있습니다. About Pluggable Protocols 문서를 참조하세요.

David Ross, MSRC