Internet Explorer 8 보안 6부 : Beta 2 업데이트
Internet Explorer 8 Beta 2 가 공개되어, 개발 팀에서 몇가지 최신 보안에 관한 소규모 변경에 대한 업데이트 정보를 간단하게 전해드립니다. Internet Explorer 8 의 XSS 필터 기능을 설계한 개발자의 훌륭한 문서들의 링크도 안내합니다.
document.domain 제한
document.domain (영어) 속성은 우선 페이지를 제공하고 있는 서버의 완전 수식 도메인 이름을 반환합니다. 이 속성은 프레임상이 다른 호스트명의 페이지에서 공유할 수 있도록 도메인suffix를 매핑해야 합니다. 예를 들면, app1.expample.com 와 app2.example.com 에서 가동하는 두 프레임은 각각의 프레임에 공통의 example.com 를 document.domain 으로 설정하면, 서로에 대한 스크립트를 기술할 수 있습니다. 프레임이 도메인 속성에 상위 수준 도메인을 설정하거나 다른 suffix를 설정할 수 없습니다. 예를 들면, app1.example.com 에는 도메인 속성에 .com 또는 microsoft.com 를 설정할 수 없습니다. HTML5 제안에서는 지정된 도메인 속성에 매핑이 허가되는지를 판정하는 알고리즘 (영어)이 정식화되어 특히 매핑값이 현재값의 suffix로 할당됩니다.
Internet Explorer 7에서는 아래와 같은 호출은 성공합니다.
// document.domain 의 초기값은 app1.example.com
document.domain = "app1.example.com"; // 1. 초기값으로 설정된 도메인 속성
document.domain = "example.com"; // 2. " 애매한 " 도메인
document.domain = "app1.example.com"; // 3. " 엄밀한 " 도메인
Internet Explorer 8 또는 다른 브라우저에서는 3번째 매핑의 app1.example.com 는 이 시점의 값인 example.com 의 suffix가 아니기 때문에 예외가 발생합니다.
간단하게 말하면,애매한 document.domain 를 지정했을 경우, 다시 엄밀한 지정을 실시할 수 없습니다 .
다른 도메인에서 데이터를 상호 호환할 필요가 있는 웹 응용 프로그램은 document.domain 의 조정보다, 오히려 postMessage() (영어) 또는 XDomainRequest APIs (영어) 이용을 검토하는 것이 좋을 것입니다.
프레임 지정 제한
HTML5에서는 어떤 프레임이 다른 이름의 프레임이나 윈도우를 지정하기 위해서 Windows.open() (영어)을 호출할 때의 targetname 매개 변수의 사용이 허용되는 상황도 규정 (영어) 합니다.
이 규정은 윈도우 삽입에 관한 취약성을 줄이는데 도움이 된다는 의미합니다. 윈도우 삽입 공격에서는 브라우저 프레임 중에 악의적 웹 사이트가 신뢰할 수 있는 웹 페이지 프레임이나 팝업을 "하이잭" 하려고 기획합니다.
예를 들면 https://contoso.com 가 helpPage 라는 이름의 팝업 창을 여는 시나리오를 가정해 주세요.
window.open("helpTopic.htm", "helpPage", "height=200,width=400");
만약 https://evil.example.com 라는 다른 페이지가 이 윈도우를 뺏어가려는 경우는 다음과 같이 됩니다 :
window.open("spoof.htm", "helpPage", "height=200,width=400");
Contoso.com 의 helpPage 윈도우에 유도되는 대신에 spoof.htm 가 새로운 브라우저 창에서 열립니다. Internet Explorer 7과 8의 모든 윈도우에서 항상 주소 표시줄을 표시하는 것과 함께 이 새로운 제한에 의해서, 윈도우 삽입에 의한 위장 가능성은 더욱 적어집니다.
MIME 처리 :Sniffing opt out
IE8 Security Part V (영어) 에서 채택한 Internet Explorer 의 MIME-Sniffing 기능은 신뢰할 수 없는 컨텐츠를 전달하는 서버로 보안 문제를 일으킬 가능성이 있습니다. 거기서 특정 HTTP 응답에 대해서 MIME-Sniffing 기능을 무효로 하기 위한, 새로운 Content-Type 특성 ("authoritative" 라는 이름)을 알리고 있었습니다.
2개월에 걸쳐, Content-Type 에 새로운 특성을 사용하는 것이 서버 관리자에서 골칫거리라는 중대한 피드백을 받았습니다. 의견을 수용하여, 이 옵션을 재검토하여, 단독의 HTTP 응답 머리글에 바꾸기 했습니다. 새로운 X-Content-Type-Options 응답 헤더의 값에 nosniff 를 설정하여 송신하면, Internet Explorer 가 MIME Sniffing 기능에서 content-type 선언을 회피하는 것을 방지할 수 있습니다.
예를 들면, 다음과 같은 HTTP-response를 부여합니다.
HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain;
X-Content-Type-Options: nosniff
<html>
<body bgcolor="#AA0000">
This page renders as HTML source code (text) in IE8.
</body>
</html>
Internet Explorer 6과 7 은 이 텍스트를 HTML 로 해석합니다.
Internet Explorer 8 은 이 페이지를 일반 텍스트로서 드로잉합니다.
신뢰할 수 없는 내용을 호스트하고 있는 사이트에서는 X-Content-Type-Options: nosniff 머리글을 이용하여 text/plain 파일이 다른 무언가에 판정되지 않게 설정할 수 있습니다.
XSS 공격 Surface Reduction : Internet Explorer 8 표준모드에서의 CSS Expression 함수 무효화
"다이내믹 속성"으로 알려진 CSS 의 Expression 함수는 높은 수준의 처리 능력을 필요로 하는 독자 확장입니다. CSS Expression 함수는 또, 서버측의 XSS 필터를 피하기 위해 공격자에서도 일반적으로 이용됩니다.
Internte Explorer 8 Beta 2에서는 CSS Expression 함수는 Internet Explorer 8 표준모드에 지원되지 않습니다. 하위호환성을 유지하기 위해 Internet Explorer 7 상호교환모드와 Quirks 모드에서는 기존대로 지원됩니다. Internet Explorer 8 의 XSS 필터는XSS 어택의 일환으로서 CSS Expression 를 반영시키는 시도를 차단할 수 있지만, Internet Explorer 8 표준모드에서 이것들을 무효로 하는 것은 처리 능력의 점에서도 유리하여, 웹 표준 준거도 개선되어 한층 더 스크립트 인젝션에 대한 공격 Surface Reduction에도 연결됩니다.
Intetnet Explorer 8 의 XSS 필터의 세부 사항
Internet Explorer 8 의 XSS 필터의 디자이너인 David Ross 가 Secure Windows Initiative (영어) 에 XSS 필터의 구조와 구현의 세부 사항에 관한 기술 문서를 발표했습니다. XSS 필터가 어떻게 동작하는지 세부 사항에 흥미가 있는 분은 구독해 주십시오.
끝까지 읽어 주셔 감사합니다.
Eric Lawrence
Program Manager
Internet Explorer Security
* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경 될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오.
영문 원본 :IE8 Security Part VI: Beta 2 Update
업데이트 일: 2008 년 9 월 2 일