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

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

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

MSHTML 엔진을 호스팅할 때 고급 IE 보안 기능을 사용하려면 어떻게 해야 하나요?

인터넷 익스플로러 6 SP2는 Feature Control Key (FCK)를 이용해서 프로세스별로 고급 브라우저 기능을 활성화하거나 비활성화 할 수 있습니다. FCK로 제어되는 기능 중에 보안과 직,간접적으로 연관된 것들이 있습니다. MSHTML을 호스팅하는 프로세스에서 각 기능의 설정을 바꾸어 명시적으로 사용하거나 (opt-in), 사용하지 않도록 (opt-out) 할 수 있습니다. 레지스트리에 FCK가 설정되어 있지 않더라도 IEXPLORER.EXE와 EXPLORER.EXE에는 대부분의 FCK가 자동으로 적용됩니다.

아래는 문서를 찾아보고 명시적으로 사용하도록 설정할만한 FCK의 목록입니다.

아래는 명시적으로 사용하지 않도록 설정할만한 FCK의 목록입니다.

FEATURE_PROTOCOL_LOCKDOWN (네트워크 프로토콜 고정) 기능은 꼭 사용할 필요가 있는 경우에만 쓰도록 하십시오. 네트워크 프로토콜 고정은 프로토콜별 영역 정책을 지원합니다. 인터넷 익스플로러에서는 기본적으로 비활성화되어 있습니다.

FCK는 CoInternetSetFeatureEnabled 함수를 호출하여 설정할 수도 있지만, 일부 FEATURE_LOCALMACHINE_LOCKDOWN 같은 FCK는 이렇게 설정하는게 지원되지 않습니다. 프로세스별로 FCK를 레지스트리에서 설정하는 방법을 사용하시기 바랍니다.

안전하게 MSHTML을 호스팅하려면 어떤 점에 주의해야 하나요?

신뢰 결정 / 스푸핑

인터넷에서 받은 임의의 내용을 호스트 프로그램이 출력하는 경우, 그 내용을 신뢰할 수 있는 것인지 사용자가 제대로 결정할 수 있도록 하는 것이 중요합니다. 인터넷 익스플로러는 강제로 주소창을 출력하고 아이콘 UI를 잠그는 방식으로 이 문제를 해결합니다. (IE7 주소창 보호)

새 창 띄우기

MSHTML 호스트에서 컨텐트가 실행되면서 새 창을 띄우는게 가능하도록 할 수 있습니다. 링크, META REFRESH 동작, 스크립트 등을 통해 새 창이 열릴 수 있습니다. 일반적인 상황에서는 MSHTML 호스트 프로그램 내의 프레임을 지정하는게 불가능합니다. (예를 들면, window.open의 두 번째 매개변수나, 앵커의 target으로 윈도우를 지정하는 것을 의미합니다.) 그러나 만약 MSHTML이 새 창을 띄우도록 허용한다면, 데스크탑에 떠있는 다른 브라우저 프로세스에서도 호스트 프로그램이 띄운 창에 접근할 수 있게 됩니다. 게다가 악성 스크립트가 실행되고 있는 상태라면, window.opener를 타고 MSHTML 호스트 환경으로 들어가거나, 스크립트를 주입할 수 있게 됩니다. 여러분이 SHDOCVW를 이용하여 MSHTML 엔진을 호스팅한다면 WebBrowser 컨트롤 이벤트를 받아서 새 창이 뜨는 경우를 제어할 수 있습니다.

IE 보호 모드

IE 보호 모드는 비스타에서 사용 가능하며, 인터넷 익스플로러 프로세스가 제한된 권한으로 실행되도록 해줍니다. 그렇지만 MSHTML을 따로 호스팅하는 경우에는 보호 모드가 지원되지 않습니다. 기본적으로 MSHTML 인스턴스는 호스트 프로그램과 동일한 무결성 수준으로 실행됩니다. (보통 Medium 무결성) 여러분은 MSHTML 인스턴스가 IE 보호 모드를 빠져나갈 수 있는 길을 열어주지 않도록 주의해야 합니다. Understanding and Working in Protected Mode Internet Explorer를 참조하세요.

호스팅할 때의 일반적인 고려 사항

Reusing MSHTML, Reusing the WebBrowser Control, WebBrowser Customization (Part 1), WebBrowser Customization (Part 2)를 참고하시기 바랍니다.

직접 IDocHostUIHandler::GetHostInfo를 구현한다면, 특히 아래의 DOCHOSTUIFLAG 값을 사용할 것인지 검토해보시기 바랍니다.

  • DOCHOSTUIFLAG_DISABLE_SCRIPT_INACTIVE
  • DOCHOSTUIFLAG_OVERRIDEBEHAVIORFACTORY
  • DOCHOSTUIFLAG_LOCAL_MACHINE_ACCESS_CHECK
  • DOCHOSTUIFLAG_DISABLE_UNTRUSTEDPROTOCOL

DOCHOSTUIFLAG_OPENNEWWIN이나 DOCHOSTUIFLAG_ENABLE_INPLACE_NAVIGATION과 같은 일부 DOCHOSTUIFLAG 값을 사용할 때에는 호스트 프로그램의 기능을 사용하는 잠재적인 공격 시나리오들을 검토해봐야 합니다.

그리고 WebBrowser 컨트롤이 어떤 웹 컨텐트를 처리하는지 알 수 없는 상황에서 안전하지 않은 동작을 수행하지 않도록 주의하십시오. 예를 들어, DWebBrowserEvents2::BeforeNavigate2 이벤트 핸들러가 특정한 경우에 목적지 URL을 매개변수로 해서 ShellExecute를 실행한다고 가정합시다. 이 경우 호스트에서 처리하는 웹 컨텐트가 신뢰할 수 없는 경우에는 악성 코드가 실행되는 결과를 초래할 수 있습니다.

WebBrowser Customization (Part 1)의 "Controlling Download and Execution" 절을 참조하시기 바랍니다. 특히 아래 값을 사용하여 보안을 강화하는 방안을 고려해보세요.

MSHTML을 HTML 미리 보기 용도로 사용하신다면, DLCTL_SILENT를 설정해서 대화 상자가 뜨지 않도록 할 수 있습니다.

"Elevated Sandbox" 호스팅 시나리오에 대한 언급

여기에서 사용되는 "elevated"라는 용어는 UAC나 IE 보호 모드와 관련이 없습니다. MSHTML 안에서 스크립트가 권한을 가지고 특별한 기능을 수행하는 경우가 있습니다. HTML Help 컨텐트의 경우, HTML Help 환경은 시스템 명령어를 실행하거나, 제어판 애플릿을 여는 등의 기능을 제공합니다. 이런 경우 임의의 HTML이나 스크립트로 공격할 수 없도록 방어해야 합니다.

이런 경우 MSHTML에 부여된 특별한 권한을 악용하거나, 임의의 코드를 실행할 수 있기 때문에, 공격자들은 MSHTML 호스팅 환경을 깨고 들어올만한 동기를 제공하게 됩니다. 공격자는 MSHTML 호스트가 특정 페이지로 이동하게 하거나, 스크립트를 주입하는 등 다양한 방식으로 공격을 시도할 수 있습니다.

실제로 이런 취약점은 여러번 발생(MS04-013, MS04-023, CAN-2003-0907)했으며, 중요 등급의 보안 패치로 이어지기도 했습니다.

특히 MSHTML 호스트가 개발 플랫폼으로 사용되는 경우에는 문제를 일으킬 가능성이 높습니다. 개발자들은 일반적으로 웹사이트 만드는 방식을 그대로 쓰게 될텐데, 그 과정에서 아래와 같은 실수를 저지르게 됩니다.

  • innerHTML을 사용하여 신뢰할 수 없는 입력값을 그대로 DOM에 쓰기
  • document.write를 사용하여 신뢰할 수 없는 입력값을 그대로 DOM에 쓰기
  • 신뢰할 수 없는 입력값을 대상으로 자바스크립트 eval() 실행
  • 프로토콜 스키마를 검증하지 않고 입력된 URL을 참조
  • SCRIPT 태그에 지정된 외부 리소스를 그대로 참조
  • 원격지의 CSS 스타일시트 참조
  • 기타 수많은 문제들.. Inspect your Gadget 문서를 참조하세요.

위와 같은 실수를 저지르면 MSHTML 호스트의 보안을 무너뜨리는 인젝션 취약점을 만들게 됩니다.

가급적 MSHTML 엔진을 호스팅하는 대신, 실버라이트나 WPF 사용을 검토해보시기 바랍니다. 실버라이트나 WPF의 경우 마크업과 코드를 잘 분리해줍니다. MSHTML 엔진을 쓰는 경우에는 개발자들이 반드시 위와 같은 보안 유의사항들을 모두 숙지하고 개발해야 합니다.

David Ross, MSRC Engineering