Internet Engineering Task Force (IETF) A. Barth
Request for Comments: 6454 Google, Inc.
범주: 표준 트랙 2011년 12월
ISSN: 2070-1721
웹 오리진 개념
초록
이 문서는 사용자 에이전트가 권한 또는 특권의 범위로 자주 사용하는
"오리진" 개념을 정의한다. 일반적으로 사용자 에이전트는 서로 다른
오리진에서 가져온 콘텐츠를 격리하여 악의적인 웹 사이트 운영자가
정상적인 웹 사이트의 동작을 방해하지 못하도록 한다. 이 문서는
오리진 개념의 기반이 되는 원칙을 개괄하는 것 외에도, URI의
오리진을 결정하는 방법과 오리진을 문자열로 직렬화하는 방법을
자세히 설명한다. 또한 HTTP 요청과 연결된 오리진을 나타내는
"Origin"이라는 HTTP 헤더 필드도 정의한다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서이다.
이 문서는 Internet Engineering Task Force(IETF)의 산출물이다.
이는 IETF 커뮤니티의 합의를 나타낸다. 이 문서는 공개 검토를
거쳤으며 Internet Engineering Steering Group(IESG)의 출판 승인을
받았다. 인터넷 표준에 관한 추가 정보는 RFC 5741의 섹션 2에서
확인할 수 있다.
이 문서의 현재 상태, 모든 정오표, 그리고 이에 대한 피드백 제공
방법에 관한 정보는
http://www.rfc-editor.org/info/rfc6454에서 확인할 수 있다.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Barth 표준 트랙 [1페이지]
RFC 6454 웹 오리진 개념 2011년 12월
목차
1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 규약 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. 적합성 기준 . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. 구문 표기법 . . . . . . . . . . . . . . . . . . . . . . 4
2.3. 용어 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. 동일 오리진 정책의 원칙 . . . . . . . . . . . . . . . . . . 4
3.1. 신뢰 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. 함정 . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. 오리진 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. 예시 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. 권한 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. 함정 . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. 정책 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. 객체 접근 . . . . . . . . . . . . . . . . . . . . . 8
3.4.2. 네트워크 접근 . . . . . . . . . . . . . . . . . . . 9
3.4.3. 함정 . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. 결론 . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. URI의 오리진 . . . . . . . . . . . . . . . . . . . . . . . 10
5. 오리진 비교 . . . . . . . . . . . . . . . . . . . . . . . 11
6. 오리진 직렬화 . . . . . . . . . . . . . . . . . . . . . . 11
6.1. 오리진의 Unicode 직렬화 . . . . . . . . . . . . . . . . 12
6.2. 오리진의 ASCII 직렬화 . . . . . . . . . . . . . . . . . 12
7. HTTP Origin 헤더 필드 . . . . . . . . . . . . . . . . . . . 13
7.1. 구문 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. 의미론 . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. 사용자 에이전트 요구사항 . . . . . . . . . . . . . . 14
8. 보안 고려사항 . . . . . . . . . . . . . . . . . . . . . . 14
8.1. DNS 의존 . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. 서로 다른 격리 단위 . . . . . . . . . . . . . . . . . 15
8.3. 주변 권한 . . . . . . . . . . . . . . . . . . . . . . 16
8.4. IDNA 의존성과 마이그레이션 . . . . . . . . . . . . . 16
9. IANA 고려사항 . . . . . . . . . . . . . . . . . . . . . . 17
10. 참고문헌 . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. 규범적 참고문헌 . . . . . . . . . . . . . . . . . . . . 17
10.2. 참고용 참고문헌 . . . . . . . . . . . . . . . . . . . . 18
부록 A. 감사의 말 . . . . . . . . . . . . . . . . . . . . . . 20
Barth 표준 트랙 [2페이지]
RFC 6454 웹 오리진 개념 2011년 12월
1. 소개
사용자 에이전트는 많은 수의 작성자가 만든 콘텐츠와 상호작용한다.
이러한 작성자 중 다수는 선의를 지니지만, 일부 작성자는 악의적일
수 있다. 사용자 에이전트가 자신이 처리하는 콘텐츠를 기반으로
동작을 수행하는 한, 사용자 에이전트 구현자는 악의적인 작성자가
다른 콘텐츠나 서버의 기밀성 또는 무결성을 방해하는 능력을
제한하고자 할 수 있다.
예로, 여러 서버에서 가져온 HTML 콘텐츠를 렌더링하는 HTTP 사용자
에이전트를 생각해 보자. 사용자 에이전트가 이러한 문서에 포함된
스크립트를 실행한다면, 사용자 에이전트 구현자는 악의적인 서버에서
가져온 스크립트가 예를 들어 방화벽 뒤에 있을 수도 있는 정직한
서버에 저장된 문서를 읽지 못하게 하고자 할 수 있다.
전통적으로 사용자 에이전트는 콘텐츠를 그 "오리진"에 따라
나누어 왔다. 더 구체적으로, 사용자 에이전트는 한 오리진에서
가져온 콘텐츠가 그 오리진에서 가져온 다른 콘텐츠와 자유롭게
상호작용하도록 허용하지만, 해당 콘텐츠가 다른 오리진의 콘텐츠와
상호작용하는 방식은 제한한다.
이 문서는 이른바 동일 오리진 정책의 배경 원칙과, 오리진을
비교하고 직렬화하는 "구체적 절차"를 설명한다. 이 문서는 동일
오리진 정책의 모든 측면을 설명하지 않는다. 그 세부사항은 HTML
[HTML] 및 WebSockets [RFC6455]와 같은 다른 명세에 맡겨져
있는데, 이는 세부사항이 대개 애플리케이션별로 다르기 때문이다.
2. 규약
2.1. 적합성 기준
이 문서에서 핵심어 "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
"OPTIONAL"은 [RFC2119]에 설명된 대로 해석되어야 한다.
알고리즘의 일부로 명령형으로 표현된 요구사항(예: "선행 공백
문자를 모두 제거한다" 또는 "false를 반환하고 이 단계를 중단한다")
은 해당 알고리즘을 소개할 때 사용한 핵심어("MUST", "SHOULD",
"MAY" 등)의 의미로 해석되어야 한다.
알고리즘이나 구체적 단계로 표현된 적합성 요구사항은 최종 결과가
동등하기만 하다면 어떤 방식으로든 구현될 수 있다. 특히, 이
명세에서 정의하는 알고리즘은 이해하기 쉽도록 의도된 것이며
성능을 높이도록 의도된 것은 아니다.
Barth 표준 트랙 [3페이지]
RFC 6454 웹 오리진 개념 2011년 12월
2.2. 구문 표기법
이 명세는 [RFC5234]의 Augmented Backus-Naur Form(ABNF)
표기법을 사용한다.
다음 핵심 규칙은 [RFC5234], 부록 B.1에 정의된 대로
참조로 포함된다: ALPHA(문자), CR(캐리지 리턴), CRLF(CR LF),
CTL(제어 문자), DIGIT(십진수 0-9), DQUOTE(큰따옴표), HEXDIG
(16진수 0-9/A-F/a-f), LF(줄 바꿈), OCTET(임의의 8비트 데이터
시퀀스), SP(공백), HTAB(수평 탭), CHAR(임의의 US-ASCII 문자),
VCHAR(임의의 표시 가능한 US-ASCII 문자), WSP(공백류).
OWS 규칙은 0개 이상의 선형 공백 옥텟이 나타날 수 있는 곳에서
사용된다. OWS는 생성하지 않거나 단일 SP로 생성하는 것이 좋다.
field-content 안에 나타나는 여러 OWS 옥텟은 필드 값을 해석하거나
메시지를 다운스트림으로 전달하기 전에 단일 SP로 대체하거나 모두
SP 옥텟으로 변환하는 것이 좋다(SP가 아닌 각 옥텟을 SP로 대체).
OWS = *( SP / HTAB / obs-fold )
; "선택적" 공백
obs-fold = CRLF ( SP / HTAB )
; 사용되지 않는 줄 접기
2.3. 용어
"user agent", "client", "server", "proxy", "origin server"라는
용어는 HTTP/1.1 명세([RFC2616], 섹션 1.3)에서와 같은
의미를 가진다.
전역적으로 고유한 식별자는 이전에 존재했던 다른 모든 값과 다른
값이다. 예를 들어, 충분히 긴 난수 문자열은 전역적으로 고유한
식별자일 가능성이 높다. 오리진 값이 사용자 에이전트 밖으로
나가지 않는다면, 사용자 에이전트에 로컬인 단조 증가 카운터도
전역적으로 고유한 식별자로 쓰일 수 있다.
3. 동일 오리진 정책의 원칙
많은 사용자 에이전트는 원격 당사자를 대신해 동작을 수행한다.
예를 들어, HTTP 사용자 에이전트는 원격 서버의 지시인 리디렉션을
따르며, HTML 사용자 에이전트는 원격 서버에서 가져온 스크립트에
풍부한 Document Object Model(DOM) 인터페이스를 노출한다.
아무 보안 모델도 없다면, 사용자 에이전트는 사용자나 다른 당사자에게
해로운 동작을 수행할 수 있다. 시간이 지나면서 많은 웹 관련
기술은 공통 보안 모델로 수렴해 왔으며,
Barth 표준 트랙 [4페이지]
RFC 6454 웹 오리진 개념 2011년 12월
이는 구어적으로 "동일 오리진 정책"이라고 알려져 있다. 이 보안
모델은 대체로 유기적으로 진화했지만, 동일 오리진 정책은 몇 가지
핵심 개념의 관점에서 이해할 수 있다. 이 절은 그러한 개념을
제시하고, 이러한 개념을 안전하게 사용하는 방법에 대한 조언을
제공한다.
3.1. 신뢰
동일 오리진 정책은 URI로 신뢰를 지정한다. 예를 들어, HTML 문서는
어떤 스크립트를 실행할지 URI로 지정한다:
<script src="https://example.com/library.js"></script>
사용자 에이전트가 이 요소를 처리할 때, 사용자 에이전트는 지정된
URI의 스크립트를 가져와 문서의 특권으로 그 스크립트를 실행한다.
이런 방식으로, 문서는 자신이 가진 모든 특권을 해당 URI가 지정한
리소스에 부여한다. 본질적으로, 문서는 그 URI에서 가져온 정보의
무결성을 신뢰한다고 선언하는 것이다.
URI에서 라이브러리를 가져오는 것 외에도, 사용자 에이전트는 URI로
지정된 원격 당사자에게 정보를 보내기도 한다. 예를 들어, 다음
HTML form 요소를 생각해 보자:
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>
사용자가 자신의 비밀번호를 입력하고 폼을 제출하면, 사용자
에이전트는 URI가 지정한 네트워크 엔드포인트로 비밀번호를 보낸다.
이런 방식으로, 문서는 자신의 비밀 데이터를 그 URI로 내보내며,
본질적으로 그 URI로 전송되는 정보의 기밀성을 신뢰한다고
선언하는 것이다.
3.1.1. 함정
동일 오리진 정책을 사용하는 새 프로토콜을 설계할 때는 중요한
신뢰 구분이 URI에 드러나도록 해야 한다. 예를 들어, Transport
Layer Security(TLS)와 비-TLS 보호 리소스가 모두 "http" URI
스킴을 사용한다면([RFC2817]에서처럼), 문서는 TLS를 통해서만
스크립트를 가져오고 싶다고 지정할 수 없게 된다. "https" URI
스킴을 사용함으로써 문서는 활성 네트워크 공격자로부터 보호되는
리소스와 상호작용하고자 함을 나타낼 수 있다.
Barth 표준 트랙 [5페이지]
RFC 6454 웹 오리진 개념 2011년 12월
3.2. 오리진
원칙적으로 사용자 에이전트는 모든 URI를 별도의 보호 도메인으로
취급하고, 한 URI에서 가져온 콘텐츠가 다른 URI와 상호작용하려면
명시적 동의를 요구할 수 있다. 안타깝게도 이 설계는 웹
애플리케이션이 종종 함께 동작하는 여러 리소스로 구성되기 때문에
개발자에게 번거롭다.
대신 사용자 에이전트는 URI들을 "오리진"이라고 불리는 보호
도메인으로 함께 묶는다. 대략적으로 말하면, 두 URI가 동일한
스킴, 호스트, 포트를 가진다면 같은 오리진의 일부이다(즉 같은
주체를 나타낸다). (전체 세부사항은 섹션 4를 참조.)
Q: 왜 호스트만 사용하지 않는가?
A: 오리진 튜플에 스킴을 포함하는 것은 보안에 필수적이다. 사용자
에이전트가 스킴을 포함하지 않는다면, http://example.com과
https://example.com은 같은 호스트를 가지므로 둘 사이에 격리가
없게 된다. 그러나 이러한 격리가 없다면, 활성 네트워크 공격자는
http://example.com에서 가져온 콘텐츠를 손상시켜 그 콘텐츠가
사용자 에이전트에 https://example.com에서 가져온 콘텐츠의
기밀성과 무결성을 침해하도록 지시하게 만들 수 있으며, TLS
[RFC5246]가 제공하는 보호를 우회할 수 있다.
Q: 왜 "최상위" 도메인만 사용하지 않고 완전 정규화된 호스트
이름을 사용하는가?
A: DNS에는 계층적 위임이 있지만, 호스트 이름 사이의 신뢰 관계는
배포 방식에 따라 달라진다. 예를 들어, 많은 교육 기관에서는
학생들이 https://example.edu/~student/에 콘텐츠를 호스팅할 수
있지만, 그렇다고 해서 학생이 작성한 문서가
https://grades.example.edu/에 호스팅된 성적 관리 웹 애플리케이션과
동일한 오리진의 일부(즉 동일한 보호 도메인에 거주)여야 한다는
뜻은 아니다.
example.edu 배포는 리소스를 오리진별로 묶는 것이 모든 배포
시나리오에 항상 완벽하게 부합하지는 않는다는 점을 보여준다.
이 배포에서는 모든 학생의 웹 사이트가 동일한 오리진에 거주하며,
이는 바람직하지 않을 수 있다. 어떤 의미에서 오리진의 세분성은
보안 모델이 진화한 방식의 역사적 산물이다.
Barth 표준 트랙 [6페이지]
RFC 6454 웹 오리진 개념 2011년 12월
3.2.1. 예시
다음 리소스는 모두 동일한 오리진을 가진다:
http://example.com/
http://example.com:80/
http://example.com/path/file
각 URI는 동일한 스킴, 호스트, 포트 구성요소를 가진다.
다음 리소스는 각각 다른 리소스들과 다른 오리진을 가진다.
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/
각 경우마다 스킴, 호스트, 포트 구성요소 중 적어도 하나가
목록의 다른 항목들과 다르다.
3.3. 권한
사용자 에이전트가 URI들을 오리진으로 묶기는 하지만, 오리진 안의
모든 리소스가 동일한 권한("authority"라는 단어의 보안적 의미에서,
[RFC3986]의 의미가 아님)을 지니는 것은 아니다. 예를 들어,
이미지는 수동적 콘텐츠이므로 권한을 지니지 않는다. 즉 이미지는
자신의 오리진에서 사용할 수 있는 객체와 리소스에 접근할 수 없다.
반대로 HTML 문서는 자신의 오리진의 전체 권한을 지니며, 문서 안의
(또는 문서로 가져온) 스크립트는 자신의 오리진 안의 모든 리소스에
접근할 수 있다.
사용자 에이전트는 리소스에 얼마나 많은 권한을 부여할지 미디어
타입을 조사하여 결정한다. 예를 들어, media type이 image/png인
리소스는 이미지로 처리되고, media type이 text/html인 리소스는
HTML 문서로 처리된다.
신뢰할 수 없는 콘텐츠(예: 사용자가 생성한 콘텐츠)를 호스팅할 때,
웹 애플리케이션은 그 미디어 타입을 제한하여 해당 콘텐츠의 권한을
제한할 수 있다. 예를 들어, 사용자가 생성한 콘텐츠를 image/png로
제공하는 것은 text/html로 제공하는 것보다 덜 위험하다. 물론 많은
웹 애플리케이션은 자신의 HTML 문서에 신뢰할 수 없는 콘텐츠를
포함한다. 신중하게 처리하지 않으면, 이러한 애플리케이션은 자신의
오리진 권한을 신뢰할 수 없는 콘텐츠에 누출할 위험이 있으며,
이는 일반적으로 교차 사이트 스크립팅이라고 알려진 취약점이다.
Barth 표준 트랙 [7페이지]
RFC 6454 웹 오리진 개념 2011년 12월
3.3.1. 함정
웹 플랫폼의 새로운 부분을 설계할 때는 미디어 타입과 관계없이
리소스에 권한을 부여하지 않도록 주의해야 한다. 많은 웹
애플리케이션은 제한된 미디어 타입으로 신뢰할 수 없는 콘텐츠를
제공한다. 이러한 콘텐츠 조각에 권한을 부여하는 새로운 웹 플랫폼
기능은 기존 애플리케이션에 취약점을 도입할 위험이 있다. 대신,
이미 오리진의 전체 권한을 지니는 미디어 타입이나 새 권한을
전달하도록 특별히 설계된 새로운 미디어 타입에 권한을 부여하는
방식을 선호해야 한다.
잘못된 미디어 타입을 제공하는 서버와 호환성을 유지하기 위해,
일부 사용자 에이전트는 "콘텐츠 스니핑"을 사용하고 콘텐츠를 서버가
제공한 미디어 타입과 다른 미디어 타입을 가진 것처럼 처리한다.
신중하게 처리하지 않으면, 콘텐츠 스니핑은 보안 취약점으로 이어질
수 있다. 사용자 에이전트가 이미지와 같은 낮은 권한의 미디어
타입에 HTML 문서와 같은 높은 권한의 미디어 타입의 특권을 부여할
수 있기 때문이다 [SNIFF].
3.4. 정책
일반적으로 말해, 사용자 에이전트는 서로 다른 오리진을 격리하고
오리진 사이의 제어된 통신을 허용한다. 사용자 에이전트가 격리와
통신을 제공하는 방식의 세부사항은 여러 요인에 따라 달라진다.
3.4.1. 객체 접근
사용자 에이전트가 노출하는 대부분의 객체(애플리케이션 프로그래밍
인터페이스 또는 API라고도 함)는 동일한 오리진에서만 사용할 수
있다. 구체적으로, 한 URI에서 가져온 콘텐츠는 다른 URI에서 가져온
콘텐츠와 연결된 객체에 접근할 수 있는데, 이는 두 URI가 동일한
오리진에 속할 때, 그리고 그때에만 가능하다. 예를 들어 동일한
스킴, 호스트, 포트를 가져야 한다.
이 일반 규칙에는 몇 가지 예외가 있다. 예를 들어, HTML의 Location
인터페이스 일부는 오리진을 넘어 사용할 수 있다(예: 다른 브라우징
컨텍스트를 탐색할 수 있도록). 또 다른 예로, HTML의 postMessage
인터페이스는 교차 오리진 통신을 명시적으로 가능하게 하기 위해
오리진을 넘어 보인다. 객체를 외부 오리진에 노출하는 것은 위험하며,
그렇게 하면 이러한 객체가 잠재적 공격자에게 노출되므로 매우
주의해서만 수행해야 한다.
Barth 표준 트랙 [8페이지]
RFC 6454 웹 오리진 개념 2011년 12월
3.4.2. 네트워크 접근
네트워크 리소스에 대한 접근은 해당 리소스가 그 리소스에 접근하려는
콘텐츠와 동일한 오리진에 있는지 여부에 따라 달라진다.
일반적으로 다른 오리진에서 정보를 읽는 것은 금지된다. 그러나 한
오리진은 다른 오리진에서 가져온 일부 종류의 리소스를 사용할 수
있다. 예를 들어, 한 오리진은 어떤 오리진에서든 스크립트를 실행하고,
이미지를 렌더링하고, 스타일시트를 적용할 수 있다. 마찬가지로,
한 오리진은 HTML 프레임 안의 HTML 문서와 같이 다른 오리진의
콘텐츠를 표시할 수 있다. 네트워크 리소스는 또한 다른 오리진이
자신의 정보를 읽도록 옵트인할 수도 있다. 예를 들어,
Cross-Origin Resource Sharing [CORS]을 사용하는 방식이다. 이러한 경우
접근은 일반적으로 오리진별로 부여된다.
다른 오리진으로 정보를 보내는 것은 허용된다. 그러나 네트워크를
통해 임의의 형식으로 정보를 보내는 것은 위험하다. 이 때문에
사용자 에이전트는 문서가 사용자 지정 헤더가 없는 HTTP 요청과 같은
특정 프로토콜을 사용해서만 정보를 보내도록 제한한다. 예를 들어
WebSockets 지원을 추가하는 방식으로 허용되는 프로토콜 집합을
확장하는 것은 취약점 도입을 피하기 위해 신중하게 이루어져야 한다
[RFC6455].
3.4.3. 함정
사용자 에이전트가 한 오리진이 다른 오리진의 리소스와 상호작용할
수 있도록 허용할 때마다, 보안 문제가 유입된다. 예를 들어, 다른
오리진의 이미지를 표시할 수 있는 능력은 그 높이와 너비를 누출한다.
마찬가지로, 다른 오리진으로 네트워크 요청을 보낼 수 있는 능력은
교차 사이트 요청 위조 취약점을 발생시킨다
[CSRF]. 그러나 사용자 에이전트 구현자는 종종 이러한 위험과
교차 오리진 상호작용을 허용하는 이점 사이에서 균형을 맞춘다.
예를 들어, 교차 오리진 네트워크 요청을 차단하는 HTML 사용자
에이전트는 사용자가 하이퍼링크를 따라가는 것을 막게 되며, 이는
웹의 핵심 기능이다.
웹 플랫폼에 새로운 기능을 추가할 때, 같은 오리진의 한 리소스에는
특권을 부여하고 다른 리소스에는 그 특권을 주지 않으려는 유혹이
생길 수 있다. 그러나 이런 식으로 특권을 보류하는 것은 효과가
없다. 특권이 없는 리소스가 대개 그 특권을 어쨌든 얻을 수 있기
때문이며, 이는 사용자 에이전트가 오리진 내부의 리소스를 격리하지
않기 때문이다. 대신, 특권은 오리진 전체에 부여하거나 보류해야
한다(오리진 안의 개별 리소스를 구별하는 방식이 아니라)
[BOFGO].
Barth 표준 트랙 [9페이지]
RFC 6454 웹 오리진 개념 2011년 12월
3.5. 결론
동일 오리진 정책은 URI를 사용하여 신뢰 관계를 지정한다. URI는
오리진으로 묶이며, 오리진은 보호 도메인을 나타낸다. 오리진의 일부
리소스(예: 능동 콘텐츠)에는 오리진의 전체 권한이 부여되는 반면,
오리진의 다른 리소스(예: 수동 콘텐츠)에는 오리진의 권한이
부여되지 않는다. 자신의 오리진 권한을 지니는 콘텐츠에는 자신의
오리진 안의 객체와 네트워크 리소스에 대한 접근이 부여된다. 또한
이 콘텐츠에는 다른 오리진의 객체와 네트워크 리소스에 대한 제한된
접근도 부여되지만, 이러한 교차 오리진 특권은 보안 취약점을
피하도록 신중하게 설계되어야 한다.
4. URI의 오리진
URI의 오리진은 다음 알고리즘으로 계산된 값이다:
1. URI가 명명 권한으로 계층적 요소를 사용하지 않거나([RFC3986],
섹션 3.2 참조), URI가 절대 URI가 아니라면, 새로운 전역
고유 식별자를 생성하고 그 값을 반환한다.
참고: 같은 URI에 대해 이 알고리즘을 여러 번 실행하면 매번
다른 값을 생성할 수 있다. 일반적으로 사용자 에이전트는 예를
들어 HTML 문서의 오리진을 한 번 계산하고, 각 보안 검사를
위해 오리진을 다시 계산하는 대신 이후의 보안 검사에 그
오리진을 사용한다.
2. uri-scheme을 URI의 스킴 구성요소를 소문자로 변환한 값으로
둔다.
3. 구현이 uri-scheme으로 주어진 프로토콜을 지원하지 않는다면,
새로운 전역 고유 식별자를 생성하고 그 값을 반환한다.
4. uri-scheme이 "file"이면, 구현은 구현 정의 값을 반환할 수
있다(MAY).
참고: 역사적으로 사용자 에이전트는 file 스킴의 콘텐츠에
매우 큰 특권을 부여해 왔다. 그러나 모든 로컬 파일에 그렇게
넓은 특권을 부여하면 특권 상승 공격으로 이어질 수 있다.
일부 사용자 에이전트는 로컬 파일에 디렉터리 기반 특권을
부여하여 성공을 거두었지만, 이 접근 방식은 널리 채택되지
않았다. 다른 사용자 에이전트는 각 file URI에 전역 고유
식별자를 사용하며, 이것이 가장 안전한 선택지이다.
Barth 표준 트랙 [10페이지]
RFC 6454 웹 오리진 개념 2011년 12월
5. uri-host를 URI의 호스트 구성요소를 소문자로 변환한 값으로
둔다([RFC4790]에 정의된 i;ascii-casemap collation 사용).
참고: 이 문서는 사용자 에이전트가 URI를 구성할 때
Internationalizing Domain Names in Applications(IDNA) 처리와
검증을 수행한다고 가정한다. 특히, 이 문서는 사용자
에이전트가 이미 비ASCII 레이블을 해당 A-label로 변환했기
때문에 uri-host가 LDH 레이블만 포함한다고 가정한다
([RFC5890] 참조). 이러한 이유로, 오리진 기반 보안 정책은
사용자 에이전트가 사용하는 IDNA 알고리즘에 민감하다. 자세한
논의는 섹션 8.4를 참조한다.
6. URI에 포트 구성요소가 없다면:
1. uri-port를 uri-scheme으로 주어진 프로토콜의 기본 포트로
둔다.
그렇지 않으면:
2. uri-port를 URI의 포트 구성요소로 둔다.
7. 삼중값(uri-scheme, uri-host, uri-port)을 반환한다.
5. 오리진 비교
두 오리진은 동일할 때, 그리고 그때에만 "같다". 특히:
o 두 오리진이 scheme/host/port 삼중값이라면, 두 오리진은 동일한
스킴, 호스트, 포트를 가질 때, 그리고 그때에만 같다.
o 전역 고유 식별자인 오리진은 scheme/host/port 삼중값인
오리진과 같을 수 없다.
두 URI는 그 오리진이 같다면 same-origin이다.
참고: URI가 반드시 자기 자신과 same-origin인 것은 아니다. 예를
들어, data URI [RFC2397]는 자기 자신과 same-origin이 아니다. data URI는
서버 기반 명명 권한을 사용하지 않기 때문에 오리진으로 전역
고유 식별자를 가지기 때문이다.
6. 오리진 직렬화
이 절은 오리진을 unicode [Unicode6] 문자열 및 ASCII [RFC20]
문자열로 직렬화하는 방법을 정의한다.
Barth 표준 트랙 [11페이지]
RFC 6454 웹 오리진 개념 2011년 12월
6.1. 오리진의 Unicode 직렬화
오리진의 unicode-serialization은 다음 알고리즘이 반환하는 값이다:
1. 오리진이 scheme/host/port 삼중값이 아니라면, 문자열
null
(즉, 코드 포인트 시퀀스 U+006E, U+0075, U+006C, U+006C)을
반환하고 이 단계를 중단한다.
2. 그렇지 않으면, result를 오리진 삼중값의 스킴 부분으로 둔다.
3. 문자열 "://"를 result에 추가한다.
4. 오리진 삼중값의 호스트 부분의 각 구성요소를(다음과 같이
변환하여) U+002E FULL STOP 코드 포인트(".")로 구분해 result에
추가한다:
1. 구성요소가 A-label이면, 대신 해당 U-label을 사용한다
([RFC5890] 및 [RFC5891] 참조).
2. 그렇지 않으면, 구성요소를 그대로 사용한다.
5. 오리진 삼중값의 포트 부분이 오리진 삼중값의 스킴 부분으로
주어진 프로토콜의 기본 포트와 다르다면:
1. U+003A COLON 코드 포인트(":")와 주어진 포트를 십진수로
result에 추가한다.
6. result를 반환한다.
6.2. 오리진의 ASCII 직렬화
오리진의 ascii-serialization은 다음 알고리즘이 반환하는 값이다:
1. 오리진이 scheme/host/port 삼중값이 아니라면, 문자열
null
(즉, 코드 포인트 시퀀스 U+006E, U+0075, U+006C, U+006C)을
반환하고 이 단계를 중단한다.
Barth 표준 트랙 [12페이지]
RFC 6454 웹 오리진 개념 2011년 12월
2. 그렇지 않으면, result를 오리진 삼중값의 스킴 부분으로 둔다.
3. 문자열 "://"를 result에 추가한다.
4. 오리진 삼중값의 호스트 부분을 result에 추가한다.
5. 오리진 삼중값의 포트 부분이 오리진 삼중값의 스킴 부분으로
주어진 프로토콜의 기본 포트와 다르다면:
1. U+003A COLON 코드 포인트(":")와 주어진 포트를 십진수로
result에 추가한다.
6. result를 반환한다.
7. HTTP Origin 헤더 필드
이 절은 HTTP Origin 헤더 필드를 정의한다.
7.1. 구문
Origin 헤더 필드는 다음 구문을 가진다:
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; RFC 3986의 <scheme>, <host>, <port>
7.2. 의미론
HTTP 요청에 포함될 때, Origin 헤더 필드는 사용자 에이전트가 요청을
발행하도록 트리거한 API가 정의하는 바에 따라, 사용자 에이전트가
요청을 발행하도록 "유발한" 오리진(들)을 나타낸다.
예를 들어, 오리진을 대신하여 스크립트를 실행하는 사용자 에이전트를
생각해 보자. 그 스크립트 중 하나가 사용자 에이전트로 하여금 HTTP
요청을 발행하게 한다면, 사용자 에이전트는 Origin 헤더 필드를
사용하여 해당 스크립트가 사용자 에이전트로 하여금 요청을 발행하게
했을 때 실행 중이던 보안 컨텍스트를 서버에 알릴 수 있다(MAY).
어떤 경우에는 여러 오리진이 사용자 에이전트가 HTTP 요청을
발행하도록 유발하는 데 기여한다. 그러한 경우 사용자 에이전트는
Origin 헤더 필드에 모든 오리진을 나열할 수 있다(MAY). 예를 들어,
HTTP 요청이 처음에는 한 오리진에 의해 발행되었지만 이후에
Barth 표준 트랙 [13페이지]
RFC 6454 웹 오리진 개념 2011년 12월
다른 오리진에 의해 리디렉션되었다면, 사용자 에이전트는 두 오리진이
사용자 에이전트가 요청을 발행하도록 유발하는 데 관여했음을 서버에
알릴 수 있다(MAY).
7.3. 사용자 에이전트 요구사항
사용자 에이전트는 모든 HTTP 요청에 Origin 헤더 필드를 포함할 수
있다(MAY).
사용자 에이전트는 어떤 HTTP 요청에도 둘 이상의 Origin 헤더 필드를
포함해서는 안 된다(MUST NOT).
사용자 에이전트가 "privacy-sensitive" 컨텍스트에서 HTTP 요청을
발행할 때마다, 사용자 에이전트는 Origin 헤더 필드에 "null" 값을
보내야 한다(MUST).
참고: 이 문서는 privacy-sensitive 컨텍스트의 개념을 정의하지
않는다. HTTP 요청을 생성하는 애플리케이션은 사용자 에이전트가
Origin 헤더 필드를 생성하는 방식에 제한을 부과하기 위해
컨텍스트를 privacy-sensitive로 지정할 수 있다.
Origin 헤더 필드를 생성할 때, 사용자 에이전트는 다음 요구사항을
충족해야 한다(MUST):
o 문법의 각 serialized-origin 생성식은 오리진의
ascii-serialization이어야 한다(MUST).
o 문법에서 연속된 두 serialized-origin 생성식은 동일할 수 없다.
특히, 사용자 에이전트가 연속된 두 serialized-origin을 생성하게
될 경우, 사용자 에이전트는 두 번째 것을 생성해서는 안 된다
(MUST NOT).
8. 보안 고려사항
동일 오리진 정책은 웹 브라우저를 포함한 많은 사용자 에이전트에서
보안의 초석 중 하나이다. 역사적으로 일부 사용자 에이전트는 taint
tracking과 exfiltration prevention을 포함한 다른 보안 모델을
시도했지만, 당시에는 그러한 모델을 구현하기 어려운 것으로
드러났다(최근에는 이러한 아이디어 일부를 되살리려는 관심이
있었지만).
동일 오리진 정책의 보안을 평가하는 것은 어렵다. 오리진 개념 자체가
보안 환경에서 매우 중심적인 역할을 하기 때문이다. 개념상의 오리진
자체는 격리 단위일 뿐이며, 대부분의 일률적인 개념과 마찬가지로
완벽하지 않다. 그렇지만 아래에서 논의하는 몇 가지 체계적 약점이
있다.
Barth 표준 트랙 [14페이지]
RFC 6454 웹 오리진 개념 2011년 12월
8.1. DNS에 대한 의존
실제로 동일 오리진 정책은 보안을 위해 Domain Name System(DNS)에
의존한다. http와 같이 흔히 사용되는 많은 URI 스킴이 DNS 기반 명명
권한을 사용하기 때문이다. DNS가 부분적으로 또는 완전히 손상되면,
동일 오리진 정책은 애플리케이션이 요구하는 보안 속성을 제공하지
못할 수 있다.
https와 같은 일부 URI 스킴은 사용자 에이전트가 인증서와 같은 다른
메커니즘을 사용하여 이러한 URI에서 가져온 콘텐츠의 출처를 검증하기
때문에 DNS 손상에 더 강하다. chrome-extension URI 스킴([CRX]의
섹션 4.3 참조)과 같은 다른 URI 스킴은 공개 키 기반 명명 권한을
사용하며 DNS 손상에 대해 완전히 안전하다.
웹 오리진 개념은 서로 다른 URI 스킴에서 가져온 콘텐츠를 격리한다.
이는 DNS 손상의 영향을 제한하는 데 필수적이다.
8.2. 서로 다른 격리 단위
시간이 지나면서 여러 기술은 편리한 격리 단위로 웹 오리진 개념에
수렴해 왔다. 그러나 오늘날 사용되는 많은 기술, 예를 들어 cookies
[RFC6265]는 현대적인 웹 오리진 개념보다 앞서 존재한다. 이러한
기술은 종종 서로 다른 격리 단위를 가지며, 이는 취약점으로 이어진다.
한 가지 대안은 완전 정규화된 도메인 이름 대신 "registry-controlled"
도메인만 격리 단위로 사용하는 것이다(예: "www.example.com" 대신
"example.com"). 이 관행은 여러 이유로 문제가 있으며 권장되지
않는다(NOT RECOMMENDED):
1. "registry-controlled" 도메인이라는 개념은 DNS 자체의 속성이
아니라 DNS를 둘러싼 인간 관행의 함수이다. 예를 들어, 일본의
많은 지방자치단체는 DNS 계층 깊은 곳에서 공용 레지스트리를
운영한다. 널리 사용되는 "public suffix lists"가 있지만, 이러한
목록은 최신 상태로 유지하기 어렵고 구현마다 다르다.
2. 이 관행은 DNS 기반 명명 권한을 사용하지 않는 URI 스킴과
호환되지 않는다. 예를 들어, 어떤 URI 스킴이 공개 키를 명명
권한으로 사용한다면, "registry-controlled" 공개 키라는 개념은
다소 일관성이 없다. 더 나쁘게는, nntp와 같은 일부 URI 스킴은
DNS와 반대 방향의 점 표기 위임을 사용하고(예: alt.usenet.kooks),
다른 스킴은 DNS를 사용하지만 레이블을 일반적인 순서의 역순으로
표시한다(예: com.example.www).
Barth 표준 트랙 [15페이지]
RFC 6454 웹 오리진 개념 2011년 12월
기껏해야 "registry-controlled" 도메인의 사용은 URI 스킴 및 구현에
따라 다르다. 최악의 경우, URI 스킴과 구현 간의 차이는 취약점으로
이어질 수 있다.
8.3. 주변 권한
동일 오리진 정책을 사용할 때, 사용자 에이전트는 콘텐츠가 지정할 수
있는 객체가 아니라 콘텐츠의 URI를 기반으로 권한을 부여한다. 이러한
지정과 권한의 분리는 주변 권한의 한 예이며 취약점으로 이어질 수
있다.
예를 들어 HTML 문서의 교차 사이트 스크립팅을 생각해 보자. 공격자가
HTML 문서에 스크립트 콘텐츠를 주입할 수 있다면, 그 스크립트는
문서 오리진의 권한으로 실행되며, 사용자의 의료 기록과 같은 민감한
정보에 접근할 수도 있다. 그러나 스크립트의 권한이 스크립트가
지정할 수 있는 객체로 제한된다면, 공격자는 제3자가 호스팅하는
HTML 문서에 스크립트를 주입해도 아무 이점을 얻지 못할 것이다.
8.4. IDNA 의존성과 마이그레이션
동일 오리진 정책의 보안 속성은 사용자 에이전트가 사용하는 IDNA
알고리즘의 세부사항에 결정적으로 의존할 수 있다. 특히, 사용자
에이전트가 IDNA2003 [RFC3490] 또는 IDNA2008 [RFC5890] 중
무엇을 사용하는지에 따라 일부 국제화 도메인 이름(예: U+00DF
문자를 포함하는 것)을 서로 다른 ASCII 표현으로 매핑할 수 있다.
한 IDNA 알고리즘에서 다른 알고리즘으로 마이그레이션하면 여러 보안
경계가 다시 그려질 수 있으며, 잠재적으로 새로운 보안 경계를
세우거나, 더 나쁘게는 서로 신뢰하지 않는 두 엔터티 사이의 보안
경계를 허물 수 있다. 보안 경계를 변경하는 것은 위험하다. 서로
신뢰하지 않는 두 엔터티를 같은 오리진으로 결합하면 한쪽이 다른
쪽을 공격할 수 있게 될 수 있기 때문이다.
Barth 표준 트랙 [16페이지]
RFC 6454 웹 오리진 개념 2011년 12월
9. IANA 고려사항
영구 메시지 헤더 필드 레지스트리([RFC3864] 참조)는 다음
등록으로 갱신되었다:
Header field name: Origin
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document: 이 명세(섹션 7)
10. 참고문헌
10.1. 규범적 참고문헌
[RFC20] Cerf, V., "네트워크 상호교환을 위한 ASCII 형식", RFC 20,
1969년 10월.
[RFC2119] Bradner, S., "RFC에서 요구사항 수준을 나타내는 데
사용하는 핵심어", BCP 14, RFC 2119, 1997년 3월.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, 1999년 6월.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "메시지 헤더
필드 등록 절차", BCP 90, RFC 3864,
2004년 9월.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, 2005년 1월.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "인터넷
애플리케이션 프로토콜 정렬 레지스트리", RFC 4790,
2007년 3월.
[RFC5234] Crocker, D., Ed. and P. Overell, "구문 명세를 위한
Augmented BNF: ABNF", STD 68, RFC 5234,
2008년 1월.
[RFC5890] Klensin, J., "애플리케이션을 위한 국제화 도메인 이름
(IDNA): 정의 및 문서 프레임워크",
RFC 5890, 2010년 8월.
Barth 표준 트랙 [17페이지]
RFC 6454 웹 오리진 개념 2011년 12월
[RFC5891] Klensin, J., "애플리케이션의 국제화 도메인 이름(IDNA):
프로토콜", RFC 5891, 2010년 8월.
[Unicode6] The Unicode Consortium, "Unicode 표준, 버전
6.0.0", 2011,
<http://www.unicode.org/versions/Unicode6.0.0/>.
10.2. 참고용 참고문헌
[BOFGO] Jackson, C. and A. Barth, "더 세분화된 오리진을
주의하라", 2008,
<http://w2spconf.com/2008/papers/s2p1.pdf>.
[CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C
Working Draft WD-cors-20100727, 2010년 7월,
<http://www.w3.org/TR/2010/WD-cors-20100727/>.
최신 버전은 <http://www.w3.org/TR/cors/>에서 이용 가능.
[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman,
"확장 기능 취약점으로부터 브라우저 보호",
2010, <http://www.isoc.org/isoc/conferences/ndss/10/pdf/
04.pdf>.
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "교차 사이트
요청 위조에 대한 견고한 방어", 2008,
<http://portal.acm.org/citation.cfm?id=1455770.1455782>.
[HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-
20110525, 2011년 5월,
<http://www.w3.org/TR/2011/WD-html5-20110525/>.
최신 버전은
<http://www.w3.org/TR/html5/>에서 이용 가능.
[RFC2397] Masinter, L., ""data" URL 스킴", RFC 2397,
1998년 8월.
[RFC2817] Khare, R. and S. Lawrence, "HTTP/1.1 내에서 TLS로
업그레이드", RFC 2817, 2000년 5월.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"애플리케이션의 국제화 도메인 이름(IDNA)",
RFC 3490, 2003년 3월.
[RFC5246] Dierks, T. and E. Rescorla, "Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, 2008년 8월.
Barth 표준 트랙 [18페이지]
RFC 6454 웹 오리진 개념 2011년 12월
[RFC6265] Barth, A., "HTTP 상태 관리 메커니즘", RFC 6265,
2011년 4월.
[RFC6455] Fette, I. and A. Melnikov, "WebSocket 프로토콜",
RFC 6455, 2011년 12월.
[SNIFF] Barth, A. and I. Hickson, "미디어 타입 스니핑", 진행
중인 작업, 2011년 5월.
Barth 표준 트랙 [19페이지]
RFC 6454 웹 오리진 개념 2011년 12월
부록 A. 감사의 말
이 문서에 귀중한 피드백을 제공해 준 Lucas Adamski, Stephen Farrell,
Miguel A. Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren,
Jeff Hodges, Collin Jackson, Larry Masinter, Alexey Melnikov, Mark
Nottingham, Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid
Stamm, Daniel Veditz, Chris Weber에게 감사드린다.
저자 주소
Adam Barth
Google, Inc.
EMail: ietf@adambarth.com
URI: http://www.adambarth.com/
Barth 표준 트랙 [20페이지]