IE8 보안 VII: ClickJacking 방지
Internet Explorer 8을 계획했었을 때, 보안팀은 현실에 일어나는 일반적인 공격과 공격자가 무엇을 다음 주의대상으로 하는지 경향을 분석했습니다. IE8 개발 과정에서 새로운 종류의 위협이 있는 곳을 알기 위해서, 보안연구 커뮤니티와 긴밀히 협력했습니다. 가장 흥미로운 웹 응용 프로그램의 취약성 중 하나는 보안연구가 Jeremiah Grossman 이 웹 취약성의 "잠자는 거인 (영어)"이라고 부른 Cross Site Request Forgery (영어)(RSRF)입니다. Jeremiah 가 보여준 것처럼, 일반적인 해결 방법이 존재하지 않기 때문에 CSRF 공격을 막는 것은 어렵습니다. 브라우저 보안모델의 구조적인 기반은 여러 웹 사이트가 동시에 상호작용 가능하여, 무관한 웹 사이트 사이를 끊김 없이 이동할 수 있도록 설계되었습니다. 그러나 이것들은 확실히 CSRF 공격이 이용하려는 기능 그 자체입니다. 최종 사용자 PC에서 개인적인 정보나 그 외의 높은 가치의 정보 저장 장소가 인기 있는 웹 응용 프로그램의 변화에 따라, CRSF 공격 (영어) 또는 그 외의 웹 응용 프로그램의 취약성으로 이어질 수 있습니다.
Internet Explorer 8 을 설계할 때 , CSRF 공격에 대한 브라우저의 공격 대상영역을 증대되지 않도록 세심한 주위를 기울였습니다. 일례로서 IE8 의 새로운 XdomainRequest 개체 (영어) 는 서버의 명시적인 허가 아래에서 크로스 도메인의 통신을 허가하지만, 새로운 유형의 CSRF 가 가능하지 않는 특정 제한을 포함합니다. 최종 사용자가 이용하지 않을 때는 민감한 정보를 취급하는 웹 사이트에서 로그오프 하거나 독립된 InPrivate Browsing 세션을 사용하여 CSRF 공격의 위협을 줄일 수 있습니다. (InPrivate 세션의 Cookie 저장 영역은 비어 있는 상태에서 시작되어, 저장된 Cookie 가 CSRF 공격으로 재사용되지 않습니다)
그렇지만 궁극적으로는 웹 응용 프로그램은 CSRF 취약성을 방지하도록 구축되어야 합니다. 최선으로 설계된 웹 응용 프로그램에서는 피해자인 사용자가 의도적으로 송신한 것인지 부정한 리퀘스트를 식별할 수 있는 챌린지 토큰 (영어) 이나 거기에 유사한 방법을 사용하여, 자신을 보호합니다. 하지만, 챌린지 토큰이나 거기에 유사한 방법은 취약성에 빠지기 쉽습니다. 가장 큰 취약성은 크로스 사이트 스크립팅(XSS)(영어)입니다. 토큰으로 보호된 웹 응용 프로그램에 크로스 사이트 스크립팅의 취약성이 있으면, 보안 토큰이 탈취되어 CSRF 공격이 가능해집니다. 다행히, Internet Explorer 8 에는 XSS 필터나 그 외의 기능 (영어) 이 있어, CSRF 를 막기 위한 챌린지 토큰의 탈취에 사용될 XSS 공격 방지에 도움이 됩니다.
작년 가을, 연구원인 Robert Hansen 과 Jeremiah Grossman 은 ClickJacking (영어) 으로 알려진, CSRF를 가능하게 하는 제 2의 요소를 공개했습니다. ClickJacking 은 사용자가 눈치채지 못하도록 애매하게 숨겨진 웹 요소를 클릭하도록 속이는데 사용되는 다중 테크닉(multiple technique) (영어)을 포함한 용어로 의도하지 않는 매매거래가 발생할 수 있습니다. 악성의 ClickJacking 공격은 사용자에 거래 확인을 요구하고 CSRF 를 막으려는 구조를 회피합니다. 예를 들면, Cookie 를 인증에 사용하고, 한번의 클릭으로 구입을 할 수 있는 단순한 웹 쇼핑몰 (영어)에 대해 생각해 봅시다.
악의가 있는 사이트 (영어)를 웹의 어딘가에서 생성하여 , 정상적인 쇼핑몰에서 표적이 되는 페이지를 IFRAME 에 의해서 꺼냅니다. 그리고 프레임내의 중요한 요소를 혼동하기 쉬운 텍스트나 이미지로 가립니다.
사용자가 속아서, 웹 쇼핑몰 페이지라고 생각하지 못하고 클릭할지도 모릅니다. 이 때 사용자가 쇼핑몰에 로그인 한 상태였을 경우, 의도하지 않는 주문이 발생합니다.
분명히, 이것은 매우 단순한 ClickJacking 공격으로, 보다 세련된 종류의 공격도 존재합니다.
ClickJacking에 대해서는 다양한 완화책 (영어) 이 만들어졌지만, 어떤 완화책에도 호환성이나 사용자 경험에 영향 혹은 기존 표준에 대한 변화의 필요성 등 절충되는 조건이 있습니다. 현시점에서, 가장 단순하고 가장 넓게 이용되는 ClickJacking 공격을 깨기 위한 메커니즘은 frame-busting 으로 공격받기 쉬운 페이지가 프레임내에서 표시되지 않도록 하는 단순한 동작을 의미 합니다. 그러나 전형적인 frame-busting (영어) 의 메커니즘은 스크립트에 의존, 그 결과 다양한 방법으로 회피됩니다.
12 월 초순에 다른 브라우저 공급업체에 개시한 것처럼, Internet Explorer 8 출시 후보에는 공격받기 쉬운 페이지를 프레임내에 표시되지 않도록 선언하여 웹 응용 프로그램이 ClickJacking 위험성을 줄일 수 있는 새로운 옵트인 메커니즘을 도입했습니다.
웹 개발자는 페이지가 프레임내에 표시되지 않도록 제한하기 위해서, X-FRAME-OPTIONS 라는 이름의 HTTP 응답 헤더를 HTML 페이지와 함께 송신할 수 있습니다. X-FRAME-OPTIONS 값에 DENY 토큰이 포함되어 있으면, 그 페이지가 프레임내에 포함된 경우에 IE8 는 페이지의 표시를 실시하지 않습니다. 값에 SAMEORIGIN 토큰이 포함되어 있으면, X-FRAME-OPTIONS 머리글을 포함한 페이지의 원래 서버와 프레임의 톱 레벨 문맥의 원래 서버가 다른 경우에 IE 는 페이지 표시를 하지 않습니다. 예를 들어, https://shop.example.com/confirm.asp 가 DENY 지시 자식을 포함하고 있으면, 부모 프레임 장소가 어디에 있는지 그 페이지 서브 프레임에는 표시되지 않습니다. 그것과는 대조적으로, X-FRAME-OPTIONS 머리글에 SAMEORIGIN 토큰이 포함된 페이지는 바르게 https://shop.example.com 를 원래 서버로 하는 페이지의 프레임내에 표시할 수 있습니다.
X-FRAME-OPTIONS 의 정책에 의해 표시가 차단되었을 경우, 제한된 설명과 프레임을 새로운 윈도우에서 열기 위한 링크가 표시된 로컬의 오류 페이지가 나타납니다. 서브 프레임 대신 새로운 윈도우에서 표시되면, 컨텐츠는 ClickJacking의 영향을 받지 않습니다.
중요한 정보를 취급하는 anti-CSRF 페이지를 보호하기 위해서 X-FRAME-OPTIONS 지시 자식을 사용하여 웹 개발자는 IE 8 사용자의 웹 응용 프로그램을 통한 공격을 즉시 줄일 수 있습니다. ClickJacking 위협에 대한 호환성이 높고 배포 하기 쉬운 방법으로 X-FRAME-OPTIONS 지시 자식이 다른 브라우저에도 구현되기를 기대합니다. 장기적으로 보면 보안연구가나 웹 표준화 조직은 브라우저에서 구현되는 웹 응용 프로그램의 보안정책의 설계가 진화를 계속한다고 예상합니다. 그들과 함께, 장래의 ClickJacking방어를 차기 버전의 브라우저는 보다 큰 보안정책 기능의 문맥 내에 형태 만드는 작업에 참여할 수 있기를 기대하고 있습니다.
감사합니다.
Eric Lawrence
프로그램 관리자
* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오.
업데이트 일: 2009 년 1 월 27 일