Internet Explorer 8 보안 5부 : 통합 보호
안녕하세요! 저는 인터넷 익스플로러 보안 프로그램의 책임자인 에릭 로렌스라고 합니다. 지난 화요일, 딘(Dean)이 신뢰성 높은 브라우저에 대한 저희의 생각을 포스팅했었죠. 오늘 저는 정말 기쁜 마음으로 인터넷 익스플로러 8의 보안을 위해 쏟아부은 엄청난 노력들에 대해 나눠보고자 합니다. 이 포스트의 길이로 짐작하시다 시피 이번 릴리즈를 위해 정말 많은 보안 관련 작업을 했습니다. 최종 사용자분들 IE8로 업그레이드를 하는 것만으로도 이 모든 보안 개선사항을 누리실 수 있고, 도메인 관리자분들은 그룹 정책과 IEAK를 이용해서 네트워크의 기본 보안 수준을 높일 수 있습니다. 웹 개발자 분들도 사용자 정보와 웹 애플리케이션을 안전하게 보호하는데 IE8에 새로 추가된 기능을 이용할 수 있고요.
인터넷 익스플로러8에 대해 기획하면서 MS의 보안팀은 현장에서 벌어지는 일반적인 공격 패턴에 대해 자세하게 관찰하여 장차 공격자들이 어떤 곳에 집중해서 공격해올지 추세를 살펴보았습니다. 보안 관련 기능들을 개발하면서 이번에 새로 추가된 강력한 기능(Activities 나 Web Slices 등의)들이 공격자들이 다음번에 노릴 표적이 되지 않도록 보안상 취약한 부분을 강화하느라 밤샘 근무도 마다하지 않았답니다. 처음의 계획에서는 좀 벗어난 얘기지만, 보안과 관련해서 다음과 같이 3가지 카테고리로 대처 방면을 구분해 보았습니다. 첫번째는 웹 애플리케이션의 취약점, 두번째는 브라우저 및 애드온의 취약점, 세번째로 사회공학적 분야, 이렇게 세 가지 방면으로 들어오는 공격에 대응하여 여러 단계의 장벽을 둘러 완벽하게 막을 수 있도록 하였습니다.
웹 애플리케이션 방어 크로스 사이트 스크립팅 공격 방어
지난 몇년간 크로스 사이트 스크립팅(XSS:Cross-Site Scripting) 공격이 버퍼 오버플로우형 공격을 추월해서 소프트웨어 취약점 공격의 가장 흔한 사례가 되어버렸습니다. XSS 공격은 웹 애플리케이션의 취약점을 공격하여 쿠키와 기타 데이터, 비공개 페이지의 정보나 신용 정보를 훔치고 장차 더 심각한 공격을 위한 준비로서 행해지고 있습니다.
IE8은 XSS 공격을 줄이고자 반사 공격(reflection)이라 불리우는 가장 일반적인 형태의 XSS 공격 패턴을 차단합니다. IE8의 XSS 필터는 추론 기반의 방어 코드로 공격 코드 주입 및 코드 실행을 방지합니다. 이 부분에 대해선 데이빗의 블로그 포스팅 - IE8 보안 4부 : XSS 필터를 보시면 더 자세하게 알수 있습니다.
XSS 필터는 이런 공격에 대한 좋은 방어책이지만, IE8에서만 제공됩니다. 따라서 웹 개발자분들은 사이트의 XSS 공격 취약점을 없애기 위해 부가적인 방어 작업을 해야 합니다. 사실 브라우저에서 XSS 공격을 탐지는 것보다 서버 단에서 막는게 더 쉽죠. 그저 사용자의 입력을 신뢰하지 않고 매번 확인과 검증을 수행하기만 하면 됩니다. 대부분의 웹 플랫폼 기술은 차단 기술을 제공하고 있습니다 ASP.NET 개발자라면 마이크로소프트 안티 XSS 라이브러리를 사용하는 것을 고려해보면 좋을 것입니다. XSS 쿠키 침해를 좀더 확실하게 막고자 한다면, 민감한 내용의 쿠키(사용자 인증등으로 사용되는)를 HttpOnly 속성으로 보호하는 것이 좋습니다.
안전한 매쉬업
XSS 필터로 브라우저가 한 서버에서 다른 서버로 이동할때 발생하는 반사 공격(reflection)을 경감시켜 줄 수는 있습니다. 하지만, Web 2.0시대가 열리면서 클라이언트 측 매쉬업을 사용하는 웹 애플리케이션이 점차 증가하고 있고 이 중 많은 매쉬업이 사용자에게 데이터 안정성을 제공해주지 못합니다. SCRIPT SRC 기술을 사용하여 써드파티의 스크립트를 바로 매쉬업 페이지에 포함시키게 되면, 써드파티의 스크립트는 해당 페이지의 DOM 객체와 HttpOnly 속성으로 보호받지 않은 쿠키를 완전히 통제할수 있게 됩니다.
이런 문제에 대처하려는 개발자 분들을 위해 IE8은 HTML5 cross-document messaging 기능을 제공하고 있습니다. 이 기능은 IFRAME으로 하여금 바깥쪽 DOM과는 격리한채로 다른 문서와 좀 더 안전하게 통신을 하도록 하고 있습니다. 또한 XDomainRequest 객체도 제공하고 있죠. 이는 다른 도메인으로부터 "공개"된 데이터를 보안 네트워크로 조회할수 있게 해줍니다.
Cross-document Messaging과 XDomainRequest 두 기능 모두 안전한 매쉬업을 작성하는데 도움을 줄 수 있습니다만, 좀 더 중요한 부분이 하나 남아있습니다. 이 기능 중 어느 것을 이용하여 서드파티의 프레임이나 서버에서 데이터를 받아오든 그 안에 script를 포함하는 문자열이 들어있을 수 있습니다. 호출자가 인지하지 못하게 DOM 객체에 그 문자열이 주입되면 바로 그것이 스크립트 주입 공격인 것입니다. 이런 상황에서 앞의 두 크로스 도메인 통신 기술과 함께 스크립트 주입 공격을 막을 2개의 신 기술을 소개 드립니다.
안전한 매쉬업 : HTML 방역
IE8 에는 window 객체에 toStaticHTML이라는 메서드 하나를 추가했습니다. HTML 코드로 이루어진 문자열이 이 함수를 거치게 되면, 잠재적으로 실행될 수 있는 스크립트 항목이 제거된 채로 리턴됩니다. 내부적으로 이 함수는 앞에서 언급한 서버측 기술인 마이크로소프트 안티 XSS 라이브러리와 동일한 기능을 수행합니다.
예제를 하나 살펴보죠. postMessage 함수 호출로 회신된 문자열에 대해 페이지 외양은 그대로 유지한채로 스크립트만 실행되지 않도록 해줍니다.
document.attachEvent('onmessage',function(e) {
if (e.domain == 'weather.example.com') {
spnWeather.innerHTML = window.toStaticHTML(e.data);
}
}
로 아래 함수가 호출되는 경우
window.toStaticHTML("This is some <b>HTML</b> with embedded script following... <script>alert('bang!');</script>!");
그 결과 값으로 아래의 문자열이 리턴됩니다.
This is some <b>HTML</b> with embedded script following... !
안전한 매쉬업: JSON 방역
JSON(JavaScript Object Notation)은 경량의 자바스크립트 객체의 스트링 직렬화로서 매쉬업에서 두 컴포넌트간의 데이터 교환에 사용되곤 합니다. 그런데 참 안타깝게도 많은 매쉬업에서 JSON을 안전하지 않게 사용하곤 합니다. 자바스크립트의 eval 메서드를 사용해서 JSON 문자열을 다시 자바스크립트 객체로 복원하곤 하는데, 이런 방식은 잠재적으로 그 실행 중에 특정 스크립트 함수를 호출할 수 있습니다. 보안에 민감한 개발자라면 JSON 파서로 JSON 객체 안에서 실행 코드가 동작 하지 않도록 합니다만, 이 경우 성능상 불이익이 있습니다.
인터넷 익스플로러 8에서는 ECMA 스크립트 3.1 규격을 구현하여 네이티브 JSON 조작 함수(Douglas Crockford의 json2.js API를 사용합니다.)를 제공합니다. JSON.stringify 메서드로 자바스크립트 객체를 JSON 문자열로 바꾸어 리턴하고, 이와 반대로 JSON.parse 메서드로 JSON 문자열을 자바스크립트 객체로 변환합니다. 새로 추가된 네이티브 JSON 메서드들은 브라우저에 내장된 스크립트 엔진과 동일한 코드를 사용하므로 여타의 네이티브 하지 않은 구현체에 비해서 엄청난 성능 우위를 제공합니다. 결과 스트링에 DOM 에 주입 코드가 들어있더라도 앞에서 언급한 toStaticHTML 함수라면 스크립트 주입 공격을 막을 수 있습니다.
아래는 스크립트 주입 공격에 대한 JSON 및 HTML 방역 예제입니다.
<html>
<head><title>XDR+JSON Test Page</title>
<script>
if (window.XDomainRequest){
var xdr1 = new XDomainRequest();
xdr1.onload = function(){
var objWeather = JSON.parse(xdr1.responseText);
var oSpan = window.document.getElementById("spnWeather");
oSpan.innerHTML = window.toStaticHTML("Tonight it will be <b>"
+ objWeather.Weather.Forecast.Tonight + "</b> in <u>"
+ objWeather.Weather.City+ "</u>.");
};
xdr1.open("POST", "https://evil.weather.example.com/getweather.aspx");
xdr1.send("98052");
}
</script></head>
<body><span id="spnWeather"></span></body>
</html>
날씨 정보 서비스가 아래와 같은 위험한 코드를 회신하더라도,
HTTP/1.1 200 OK
Content-Type: application/json
XDomainRequestAllowed: 1
{"Weather": {
"City": "Seattle",
"Zip": 98052,
"Forecast": {
"Today": "Sunny",
"Tonight": "<script defer>alert('bang!')</script>Dark",
"Tomorrow": "Sunny"
}
}}
이를 잘 막아냅니다.
MIME 핸들링
웹서버에서 전송되는 모든 파일은 MIME 타입 (혹은 Content-type이라고도 하죠.)에 따르고 있습니다. 이것은 해당 컨텐츠가 어떤 컨텐츠인지 (이미지인지 텍스트인지 애플리케이션인지) 나타내 줍니다. 호환성을 이유로 인터넷 익스플로러에는 각 다운로드되는 리소스들의 컨텐츠 타입이 무엇인지 확인하는 MIME 스니핑 기능이 탑재되어 있었습니다. 가끔씩 인터넷 익스플로러가 웹서버에 정의된 MIME 타입과 다른게 판별하는 경우가 있습니다. 예를 들어 HTTP 응답 헤더에 Content-Type:text/plan 으로 회신된 파일이 HTML 문서라고 판별했다면, IE는 이 파일을 HTML로 렌더링 하기로 판단합니다. MIME 스니핑은 수많은 레거시 웹서버들 (html 문서를 text/plain으로 보내주기 때문입니다.) 와 호환되도록 하는 중요한 기능을 수행합니다.
하지만 아쉽게도 MIME 스니핑은 신뢰할수 없는 컨텐츠를 제공하는 서버의 경우엔 주요한 보안 문제를 야기합니다. 다음과 같은 경우를 가정해보죠. 사진 공유 서비스에 아무나 이미지 파일을 업로드 할 수 있는 상황에서, 공격자가 JPEG 파일을 가공하여 공격 코드가 내장된 이미지 파일을 업로드 했다면 불특정 다수의 피해자를 양산 할 수 있습니다. 사진 공유 사이트에서 일반 이미지 처럼 동작하지만 내장된 스크립트 역시 동작하는 위험한 파일을 사용자가 다운로드 받으면 이 코드가 피해자의 쿠키를 훔치거나 위조 페이지로 이동하는 등의 작업이 가능해집니다.
이런 문제에 대응하고자 우리는 인터넷 익스플로러 8의 MIME-type 판별 코드에 아래와 같은 수정을 가했습니다.
MIME 핸들링 : "Upsniff" 제한
우선 IE8에서 "upsniff"를 막아서 파일의 MIME type이 image/* 인데도 HTML/Script로 판별되는 것을 방지합니다. 파일에 스크립트가 내장되어 있으면, 서버가 아무리 이 파일을 이미지라고 선언해도 IE는 내장된 스크립트를 실행하지 않습니다. 이 변화로 인해 사진 공유사이트의 서버쪽 코드를 전혀 고치지 않고도 이에 대한 공격을 막을 수 있게 되었습니다. 이렇게 해도 호환성 문제를 최소화 할수 있는 것은 서버들이 image/* 컨텐츠 타입을 HTML이나 스크립트로 판별하는 경우가 드물기 때문입니다.
MIME 핸들링 : 스니핑 Opt-out
다음으론, 웹 애플리케이션에 MIME 스니핑을 opt-out 하는 기능을 제공합니다. Content-Type HTTP 응답에 authorutative=true 속성을 추가하면 인터넷 익스플로러는 MIME 스니핑을 수행하지 않습니다.
예컨대 아래와 같은 HTTP-response 에 대해
HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain; authoritative=true;
<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>
IE7 에서는 HTML로 해석되어 화면에 출력되지만,
IE8에서는 평범한 텍스트 파일로 출력됩니다.
신뢰할수 없는 컨텐츠를 제공하는 공공 사이트에선 헤더에 authoritative 속성만 추가해주면 text/plain으로 확정되어 아무것도 가로챌 수 없게 됩니다.
MIME 핸들링 : 강제 저장
마지막으로 신뢰할 수 없는 HTML 파일을 다운로드 하도록 웹 애플리케이션을 만들어야 할 경우 대해 신뢰할 수 없는 컨텐츠의 실행을 막아 여러분의 사이트 보안성이 유지되도록 하였습니다. 헤더에 X-Download-Options를 추가하고 noopen을 값을 세팅하면 해당 파일이 실행되는 대신 무조건 다운로드만 됩니다. 일단 다운로드 된 파일이 로컬에 저장되면 다음에 다시 실행되더라도 여러분의 사이트에 위해를 끼칠 수 없게 되어 스크립트 주입 공격을 막을 수 있게 됩니다.
HTTP/1.1 200 OK
Content-Length: 238
Content-Type: text/html
X-Download-Options: noopen
Content-Disposition: attachment; filename=untrustedfile.html
앞에서 나열한 일련의 웹 애플리케이션 방어 기능들을 모두 사용한다면 좀 더 안전한 웹 애플리케이션 개발이 가능해질 것입니다.
로컬 브라우저 방어
웹 애플리케이션에 대한 공격이 증가하면서 공격자들은 점차 일반 사용자의 로컬 컴퓨터를 표적으로 삼고 있습니다. 브라우저에 보안정책을 보다 효과적으로 강제하기 위해선 웹 애플리케이션, 개인 정보, 로컬 자원, 브라우저 자체에 대한 공격을 예방해야합니다. 그런 점에서 보호 모드, ActiveX Opt-in, Zone-Lockdown 같은 기술을 탑재한 인터넷 익스플로러 7은 중요한 발전이라 할수 있습니다. 이렇게 브라우저 공격이 난관에 부딛히자 공격자들은 브라우저의 추가 기능의 취약점에 집중하기 시작합니다.
인터넷 익스플로러 8에선 발전된 추가기능 보안, 공격 가능 지점 최소화, 개발 용이성 및 발전된 사용자 경험을 위해 많은 노력을 기울였습니다.
추가기능(Add-on) 보안
이 보안 블로그를 처음 시작할때 DEP/NX 메모리 보호에 관련된 시리즈로 시작했었습니다. 이 기능은 IE8이 윈도우 서버 2008, 윈도우 비스타 SP1, 윈도우 XP SP3 에서 실행될 때 자동으로 활성화 됩니다. DEP/NX 기술을 ASLR (Address Space Layout Randomization) 같은 기술과 결합하여 공격자가 버퍼오버런 같은 메모리 관련 취약점 공격을 쉽게 하지 못하도록 합니다. 무엇보다도 이 보호 기술이 인터넷 익스플로러 뿐만 아니라 같이 로딩되는 추가기능에도 동시에 적용된다는 점이 중요합니다. 여기에 관해선 이 블로그 시리즈의 첫 글 : IE8 보안 1부: DEP/NX 메모리 보호를 읽어보세요.
그 다음에 이어진 연재글에서 매트 크롤리(Matt Crowley)씨가 IE8 에서의 ActiveX 개선 사항 및 이전 버전의 브라우저에서 부터 이어진 ActiveX 보안 기능을 설명했었죠. 가장 중요한 개선사항은 "Per-Site ActiveX"라고 할수 있는데, 이는 ActiveX 컨트롤이 악성 코드로서 동작하지 않도록 해줍니다. IE8은 ActieveX 를 관리자 권한이 없이도 설치할 수 있도록 하였습니다. 도메인 관리자를 활성화 하기만 하면 대부분의 관리자 권한이 없는 사용자도 설치하고 사용할 수 있게 된거죠. 이 부분에 대해선 IE8 보안 2부: ActiveX 보안 개선을 읽어보시면 좋을 것입니다. ActiveX 개발자 분들의 경우엔 이 페이지를 참고하시면 사용자 보호에 큰 도움이 될 것입니다.
보호 모드
보호모드는 윈도우 비스타의 IE7에서 처음 선보인 기능으로, 인터넷 익스플로러와 그 위에서 동작하는 확장 기능에 소프트웨어의 취약점이 있더라도 악성코드가 사용자 몰래 설치되는 것을 방지하여 그 위험도를 줄여줍니다. 인터넷 익스플로러 8 에서는 상당수의 API를 보호 모드에 맞게 개선하여 애드온 개발자들이 보호모드에서 동작하는 브라우저 인스턴스를 쉽게 컨트롤하고 상호 작용 할 수 있도록 하였습니다. 이 개선점에 대해선 개선된 보호모드 API 백서를 보세요.
성능 향상과 애플리케이션 호환성을 위해 인트라넷 영역에선 기본 설정으로 IE8의 보호모드를 비활성화하도록 하였습니다. 원래에는 UX(사용자 경험)와 관련된 이유로 인트라넷 영역에서도 활성화되있었고 그런 이유로 보호 모드로 바뀌거나 보호 모드에서 벗어날 때 인터넷 익스플로러 7이 강제적으로 새 프로세스를 할당하고 새 창을 띄우곤 했었습니다.
인터넷 익스플로러의 유연한 구조 덕분에 한 브라우저 창에 보호 모드로 동작하는 창과 보호 모드로 동작하지 않은 창을 동시에 띄울 수 있게 되었습니다. 따라서 사용자가 혼란을 느끼지 않고도 쉽게 사용할 수 있게 되었죠. 물론 IE8 사용자나 도메인 관리자는 필요한 경우엔 보호 모드를 활성화 하도록 설정을 변경할 수 있답니다.
애플리케이션 프로토콜 알림
애플리케이션 프로토콜 핸들러는 (인터넷 전화 애플리케이션이나 스트리밍 미디어 플레이어 같은) 서드파티 애플리케이션을 브라우저 내에서 혹은 윈도우에 설치된 별도 애플리케이션을 바로 기동할 수 있게 해줍니다. 이것은 매우 강력한 기능이지만 아쉽게도 보안상 취약한 부분입니다. 인터넷에 떠돌아다니는 안전하다고 확인되지 않은 컨텐츠로 인해 보안 취약점이 발생할 수 있기 때문입니다.
사용자가 이 기능을 사용할지 선택 할 수 있도록 인터넷 익스플로러 8에선 애플리케이션 프로토콜을 실행하기 전에 사용자에게 이를 사용할지 알리게 됩니다.
이 부분에 대해 좀 더 잘 대처하시려는 애플리케이션 프로토콜 개발자분들은 MSDN의 Best Practice 문서를 따르시면 됩니다.
파일 업로드 컨트롤
역사적으로 HTML 파일 업로드 컨트롤(<input type="file">)은 수많은 정보 누출 취약점으로 지적되었습니다. 이 문제를 해결하기 위해 두가지 부분을 수정하였습니다.
사용자가 업로드 할 파일 경로를 직접 입력하도록 하고 키 눌림 정보를 훔치는 방식의 공격을 막고자 업로드 컨트롤의 파일 주소 표시 박스를 읽기만 가능하도록 변경했습니다. 이제 사용자는 파일 선택창을 띄워야만 업로드가 가능해집니다.
추가적으로 "업로드 될 파일의 로컬 디렉토리 경로 정보"를 표시하는 URLAction 기능이 "Disable"로 설정되었습니다. 그 결과, 로컬 파일 시스템에 대한 정보가 노출되는 잠재적 위험을 막을 수 있게 되었습니다. 예를 들어 서브밋 버튼을 누를 경우 인터넷 익스플로러 8에선 C:\users\ericlaw\documents\secret\image.png 이런 경로의 이미지 전체 경로를 보내는 것이 아니라 image.png 정보만 보내게 됩니다.
사회공학적 방어
브라우저가 지난 몇 년동안 많은 발전을 해 옴에 따라 웹상의 범죄자들은 사회공학적인 방법으로 사용자를 공격하기 시작했습니다. 잘 방어된 성벽을 공격하기보다 당당하게 성문앞에 다가와서 사용자들에게 자신이 믿게끔 속인다는 것이죠.
인터넷 익스플로러 8 에서는 여러 사이트들과 신뢰할만한 기관으로부터 제공된 정보를 바탕으로 사용자가 이런 경우에 잘못된 선택을 하지 않도록 도와주는 기능에 많은 노력을 기울였습니다.
주소 표시줄 개선
도메인 강조는 IE8 Beta 1에 추가된 신 기능으로 사용자로 하여금 쉽게 웹 주소(URL)를 인지하게 해줍니다. 도메인 이름이야 말로 URL에서 보안에 가장 중요한 부분이므로 이를 검은 글씨로 강조하고 사이트에서 관리하는 쿼리 스트링 같은 URL 문자는 회색으로 표시합니다.
EV SSL 인증서 등의 기술을 사용한 사이트에 대해선 사용자가 민감한 데이터를 사용자가 신뢰하는 사이트에만 제공되고 있음을 쉽게 인지 할 수 있도록 인터넷 익스플로러 8의 주소표시줄을 강조합니다.
SmartScreen® 필터
인터넷 익스플로러 7에서 피싱 필터가 처음으로 도입되어서 보고된 피싱사이트에 접속하려 할때 사용자가 인지할 수 있도록 했습니다. 인터넷 익스플로러 8에선 성공적으로 자리잡은 피싱 필터를 좀 더 개량한 SmartScreen® 필터가 도입되었습니다. SmartScreen® 필터는 피싱 사이트에 접속했다는 것을 알려주는 것 이상으로 악성코드가 배포된다고 알려진 사이트를 차단하거나 악성코드가 사용자의 컴퓨터에 공격을 시도하거나 개인정보를 침해할려고 하면 이를 사용자에게 알려줍니다. 사용자 컴퓨터에 대한 종합적인 보호를 위해 단독으로 동작하는 것이 아니라 윈도우 디펜더나 윈도우 라이브 원케어와 같은 기술과 결합하여 이를 수행합니다.
보다 자세한 내용은 이전의 포스트 : IE8 보안 3부 - 스마트스크린 필터를 보세요.
결론
보안은 신뢰성 있는 웹 브라우징의 핵심 사항입니다. 인터넷 익스플로러 8에 추가된 주요 개선 사항을 통해 웹 보안 전반에 진화를 이루었습니다. 악의 무리들이 "GG" 치고 나가지 않는 한 우리 IE팀은 웹 애플리케이션 보안성 증대와 사용자 보호를 위해선 불철주야로 노력하고 있습니다.
앞으로도 IEBlog에 자주 들르셔서 우리 팀이 안전하고도 믿을 수 있고 이용하기 편리한 브라우저를 만들어가는 과정을 지켜봐주세요.
8월에 출시될 베타 2도 기대해 주시구요!
에릭 로렌스
프로그램 매니저
* 역자 : 이글은 IE8 Security Part V: Comprehensive Protection (영문)을 NCHOVY 인터넷스톰센터에서 번역해 주셨습니다. 진심으로 감사의 말씀을 드립니다.