요약

  • X-Frame-Options: SAMEORIGIN은 웹페이지가 다른 사이트의 프레임에 들어가지 않겠다고 브라우저에 알리는 응답 헤더였다. 2013년 RFC는 보호 페이지와 가장 바깥쪽 페이지만 비교하는 구현의 빈틈을 기록했다.
  • A 사이트가 B 페이지를 넣고, B가 다시 A의 보호 페이지를 넣으면 양 끝은 A와 A다. 바깥쪽만 보는 검사는 중간의 B를 놓친다. W3C의 2016년 frame-ancestors는 모든 상위 프레임을 확인하도록 했다.

같은 두 페이지 사이의 다른 하나

A 사이트의 바깥 페이지 안에 B 사이트의 프레임이 있다. B는 그 안에 A의 민감한 페이지를 넣으려 한다. 안쪽 A가 X-Frame-Options: SAMEORIGIN을 보낸다. 같은 출처의 페이지에서만 자신을 프레임으로 보여 달라는 뜻이다. 브라우저가 안쪽 A와 가장 바깥쪽 A만 비교하면 출처가 일치하므로 통과시킨다. 보호 페이지를 바로 둘러싼 B는 검사에서 빠진다.

이 구조는 2013년 10월의 RFC 7034에 나온다. 당시 헤더 사용과 브라우저 구현 차이를 정리한 정보성 문서다. 헤더가 겨냥한 것은 클릭재킹이었다. 한 페이지가 다른 페이지의 버튼 위에 화면을 겹쳐, 이용자가 의도하지 않은 곳을 누르게 할 수 있다. RFC의 쇼핑몰 구매 확인은 방어를 설명하는 사례다. A/B/A 구조도 기술적 가능성을 보여 주며 특정 상점의 침해 사건을 세는 자료는 아니다.

서버는 경계를 썼고 브라우저는 짧게 읽었다

보호할 사이트는 HTTP 응답에 X-Frame-Options를 담았다. DENY는 모든 프레임을 거부하고, SAMEORIGIN은 같은 출처를 허용하며, ALLOW-FROM은 허용할 출처 하나를 지정했다. 사이트가 경계를 정하고 브라우저가 지킨다는 역할 분담이다. 그러나 프레임이 세 겹이면 어떤 페이지의 출처를 비교하는지가 핵심이다.

RFC는 구현 방식이 브라우저마다 달랐다고 적었다. 일부는 가장 위 문서와 보호 페이지의 출처만 맞춰 보고 중간의 낯선 프레임을 살피지 않았다. 사이트가 올바른 문자열을 보내도 실제 검사는 조상 전체를 따라가지 못했다. 길의 시작과 끝이 같은 주인에게 속한다고 해서 가운데 통로까지 그렇다는 보장은 없다.

조상을 전부 검사하다

W3C가 2016년 12월 발표한 Content Security Policy Level 2 권고는 frame-ancestors를 정의했다. 보호 페이지를 프레임에 불러오기 전에 브라우저가 모든 상위 창을 목록으로 만들고, 각 문서의 주소를 허용된 출처와 대조한다. 하나라도 맞지 않으면 로딩을 멈춘다. A/B/A 구조에서는 중간 B가 탈락한다. 바깥 A가 허용 대상이어도 결과는 같다.

W3C는 이 전 계층 검사와 여러 옛 SAMEORIGIN 구현의 최상위 비교를 직접 구별했다. frame-ancestors가 X-Frame-Options를 대체하며 두 정책이 함께 오면 CSP 쪽을 적용해야 한다고 했다. 새 규칙은 허용할 출처를 여러 개 적을 수도 있다. 가장 큰 변화는 목록의 길이보다 검사 범위였다.

정책을 놓는 위치도 중요했다. RFC는 meta http-equiv에 적은 X-Frame-Options를 브라우저가 무시한다고 설명했다. W3C 역시 meta 요소로 전달한 frame-ancestors를 인정하지 않았다. default-src 'none'을 적는다고 프레임 삽입까지 자동으로 금지되지도 않는다. 사이트는 브라우저가 실제 처리하는 응답에 삽입 경계를 명시해야 했다.

페이지 소유자는 누가 자신을 둘러쌀지 선언한다. 방문자의 브라우저만 실제 프레임 전체를 볼 수 있다. 선언의 효력은 브라우저가 몇 겹까지 확인하느냐에 달려 있었다.