기타/WWW

동일출처정책(Same-origin policy)

하늘이푸른오늘 2014. 1. 21. 17:09

이 문서는 영문 위키피디아 문서를 번역한 것입니다.

====


컴퓨팅에서 동일출처정책은 자바스크립트(Javascript)와 같은 브라우저측 프로그래밍 언어에서 중요한 보안 개념이다. 이 정책에 의하면, 동일한 사이트에서 나온 페이지에서 돌아가는 스크립트는 별다른 제한 없이 서로의 DOM을 접근할 수 있지만, 다른 사이트에 있는 DOM은 접근이 허용되지 않는다. 여기에서 동일한 사이트란 scheme, 호스트이름 및 포트번호를 조합한 것이다. 동일출처정책은 XMLHttpRequest 및 robots.txt에도 적용된다.


In computing, the same-origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The policy permits scripts running on pages originating from the same site – a combination of scheme, hostname, and port number – to access each other's DOM with no specific restrictions, but prevents access to DOM on different sites. Same-origin policy also applies to XMLHttpRequest and to robots.txt.


이 메카니즘은 입증된 사용자 세션(authenticated user sessions)을 유지하기 위해 HTTP 쿠키에 널리 의존하는 현대적 웹 어플리케이션에서 특별히 중요하다. HTTP 쿠키 정보에 근거하여, 서버가 민감한 정보를 제공하거나 상태가 변경되는 액션을 취하기 때문이다. 데이터의 기밀이나 일관성을 유지하기 위해서는, 클라이언트측에서 관계없는 사이트로부터 제공된 콘텐트를 엄격하게 분리해야 한다.


This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity.


역사(History)


동일출처정책의 개념은 1995년 넷스케이프사의 내비게이터2로 거슬러 올라간다. 원래의 개념과 거의 비슷한 개념이 현재 모든 브라우저에 사용되고 있으며, 얼추 호환성있는 다른 웹 스크립팅 언어 (아도비 플래시 혹은 아도비 아크로뱃)이나, 직접적인 DOM 처리와는 완전히 다른 XMLHttpRequest 같은 메카니즘에도 확장 적용되고 있다. 


The concept of same-origin policy dates back to Netscape Navigator 2 in 1995. Close derivatives of the original design are used in all current browsers[citation needed] and are often extended to define roughly compatible security boundaries for other web scripting languages, such as Adobe Flash or Adobe Acrobat, or for mechanisms other than direct DOM manipulation, such as XMLHttpRequest.


출처결정원칙(Origin determination rules)


URI의 출처를 계산하는데 사용되는 알고리듬은 RFC 6454  4절에 정의되어 있다. 절대 URI의 출처는 {protocol, host, port} 등 세가지로 구성된다. URI가 naming authority(RFC 3986, Section 3.2 참고)와 같은 계층적 요소를 사용하지 않거나, URI가 절대 URI가 아니라면, globally unique identifier 가 사용된다. 이 모든 값이 정확하게 같을 경우에만 두개의 자원이 동일출처로 간주된다. 


The algorithm used to calculate the "origin" of a URI is specified in RFC 6454, Section 4. For absolute URIs, the origin is the triple {protocol, host, port}. If the URI does not use a hierarchical element as a naming authority (see RFC 3986, Section 3.2) or if the URI is not an absolute URI, then a globally unique identifier is used. Two resources are considered to be of the same origin if and only if all these values are exactly the same. 


아래는 "http://www.example.com/dir/page.html" 에 대하여 체크를 했을 때의 개략적인 전형적 결과를 보여주는 표이다.


To illustrate, the following table gives an overview of typical outcomes for checks against the URL "http://www.example.com/dir/page.html".


비교대상 URL결과Reason
httpː//www.example.com/dir/page2.htmlSuccess프로토콜과 호스트 동일
httpː//www.example.com/dir2/other.htmlSuccess프로토콜과 호스트 동일
httpː//username:password@www.example.com
/dir2/other.html
Success프로토콜과 호스트 동일
httpː//www.example.com:81/dir/other.htmlFailure포트가 다름
https://www.example.com/dir/other.htmlFailure프로토콜이 다름
http://en.example.com/dir/other.htmlFailure호스트가 다름
http://example.com/dir/other.htmlFailure호스트가 다름(정확히 일치해야)
http://v2.www.example.com/dir/other.htmlFailure호스트가 다름(정확히 일치해야)
httpː//www.example.com:80/dir/other.htmlDon't use서버에 따라 다름


다른 브라우저와는 달리 IE는 출처를 결정할 때 포트는 사용하지 않는다. 대신 Security Zone을 사용한다.


Unlike other browsers, Internet Explorer does not include the port in the calculation of the origin, using the Security Zone in its place.


동일출처정책의 회피(Relaxing the same-origin policy)


경우에 따라서는 동일출처 정책은 너무 제한이 많아서 서브-도메인이 많은 대규모 웹사이타 같은 경우 문제를 일으키고 있다. 아래는 이를 회피하는 네가지 기법이다.


In some circumstances the same-origin policy is too restrictive, posing problems for large websites that use multiple subdomains. Here are four techniques for relaxing it:


document.domain 프로퍼티를 사용하는 방법


두개의 윈도(혹은 프레임)에 도메인을 같은 값으로 설정하는 스크립트가 있을 경우, 동일출처정책은 이 두개의 윈도간에는 완화되어, 한 윈도가 다른 윈도와 상호작용할 수 있다. 예를 들어, orders.example.com 과catalog.example.com 에서 불러온 문서에 포함된 스크립트가 document.domain 프로퍼티를 "example.com"으로 설정하면, 이에 따라 문서가 동일한 출처인 것처럼 보이게 되어, 한 문서가 다른 문서의 프로퍼티를 읽을 수 있게 된다. 이것은 내부 표현에 저장된 포트가 null로 표시될 수 있기 때문에 항상 잘 작동하는 것은 아니다. 예를 들어, document.domain을 갱신함으로써, example.com:80 이 example.com 으로 바뀌게 된다는 것이다. 포트번호가 없으면 80으로 취급되지 않을 수도 있으므로(브라우저에 따라 다름), 브라우저에 따라 성공할 수도 실패할 수도 있다. 


If two windows (or frames) contain scripts that set domain to the same value, the same-origin policy is relaxed for these two windows, and each window can interact with the other. For example, cooperating scripts in documents loaded from orders.example.com and catalog.example.com might set their document.domain properties to “example.com”, thereby making the documents appear to have the same origin and enabling each document to read properties of the other. This might not always work as the port stored in the internal representation can become marked as null. In other words example.com port 80 will become example.com port null because we update document.domain . Port null might not be treated as 80 ( depending on your browser ) and hence might fail or succeed depending on your browser.


Cross-Origin Resource Sharing(CORS


동일출처 정책을 회피하는 두번째 기법은 출처 자원공유(CORS : Cross-Origin Resource Sharing)라는 이름으로 표준화되었다. 이 표준초안에는 HTTP에 새로운 Origin 요청 헤더와 새로운 Access-Control-Allow-Origin 응답 헤더를 추가하였다. 이를 통해 서버에서는 파일 요청을 허용한 명시적인 출처(origin) 리스트에 헤더를 사용하거나 혹은 와일드카드(*)를 사용하여 모든 사이트가 파일을 요청할 수 있도록 허용할 수 있다. 파이어폭스 3.5와 사파리 4와 같은 브라우저는 이러한 새로운 헤더를 사용하여 XMLHttpRequest를 사용한 동일출처를 벗어난 HTTP 요청을 허용하고 있다. CORS가 아니었다면 동일출처정책에 의해 금지되었을 것이다.


The second technique for relaxing the same-origin policy is being standardized under the name Cross-Origin Resource Sharing. This draft standard extends HTTP with a new Origin request header and a new Access-Control-Allow-Origin response header. It allows servers to use a header to explicitly list origins that may request a file or to use a wildcard and allow a file to be requested by any site. Browsers such as Firefox 3.5 and Safari 4 use this new header to allow the cross-origin HTTP requests with XMLHttpRequest that would otherwise have been forbidden by the same-origin policy.


크로스 다큐먼트 메시징(Cross-document messaging)

또다른 새로운 기법인 크로스 다큐먼트 메시징을 사용하면 어떤 페이지에 있는 스크립트로부터 다른 페이지에 있는 스크립트에 (스크립트 출처에 관계없이) 텍스트 메시지를 전달할 수 있다. Window 객체에 있는 postMessage() 메소드를 호출하면 해당 윈도에 비동기적으로 "onmessage" 이벤트를 발생시켜, 사용자 정의 이벤트핸들러를 부를 수 있다. 한 페이지에 있는 스크립트는 여전히 다른 페이지에 있는 메소드나 변수에 직접적으로 접근할 수는 없으나, 메시지 전달 기법을 통해 안전하게 통신할 수 있다.


Another new technique, cross-document messaging allows a script from one page to pass textual messages to a script on another page regardless of the script origins. Calling the postMessage() method on a Window object asynchronously fires an "onmessage" event in that window, triggering any user-defined event handlers. A script in one page still cannot directly access methods or variables in the other page, but they can communicate safely through this message-passing technique.


JSONP

JSONP를 사용하면 다른 도메인으로부터 JSON 데이터를 받을 수 있다. 그 페이지에 다른 도메인으로부터 JSON 응답을 받을 수 있는 <script> 요소를 추가하면 된다.


JSONP allows a page to receive JSON data from a different domain by adding a <script> element to the page which loads a JSON response from a different domain.


극단적 조건 및 예외(Corner cases and exceptions)


동일출처 점검 및 관련 메카니즘의 행태는 여러가지 극단적 조건에서는 잘 정의되지 않는다. 예를 들어 URL에 명확하게 정의된 호스트이름이나 포트가 없는 (file:, data:, 등) 가상 프로토콜(pseudo-protocol)등에서 이런 문제가 발생한다. 이는 역사적으로 여러가지 보안문제를 발생시켰다. 예를 들어 로칼에 저장된 HTML 파일이 디스크에 있는 모든 파일에 접근할 수 있다던가, 인터넷상의 모든 사이트와 통신할 수 있는 등 일반적으로 바람직하지 않는 기능 등이 문제가 되었다.


The behavior of same-origin checks and related mechanisms is not well-defined in a number of corner cases, such as for pseudo-protocols that do not have a clearly defined host name or port associated with their URLs (file:, data:, etc.). This historically caused a fair number of security problems, such as the generally undesirable ability of any locally stored HTML file to access all other files on the disk, or communicate with any site on the Internet.


아울러 자바스크립트 이전의 많은 합법적 크로스도메인 작업에 대해서는 동일출처 점검에 해당되지 않는다. 이러한 예로서, 다른 도메인으로부터 스크립트를 불러오는 것이나, 폼을 POST 하는 것 등이 있다.


In addition, many legacy cross-domain operations predating JavaScript are not subjected to same-origin checks; one such example is the ability to include scripts across domains, or submit POST forms.


마지막으로 DNS 리바인딩이나 서버측 프록시와 같은 일부 공격을 통하면 호스트이름 점검을 부분적으로 망가뜨림으로써, 원래의 진짜 출처가 아닌 주소를 통해서 가짜 웹페이지가 직접 해당사이트를 조작할 수 있게된다. 이러한 공격의 효과는 아주 특별할 시나리오에 한한다. 브라우저의 입장에서는 공격자의 사이트와 통신한다고 믿고 있으며, 따라서 제3의 쿠키나 다른 민감한 정보를 공격자에게 노출시키지 않기 때문이다.


Lastly, certain types of attacks, such as DNS rebinding or server-side proxies, permit the host name check to be partly subverted, and make it possible for rogue web pages to directly interact with sites through addresses other than their "true", canonical origin. The impact of such attacks is limited to very specific scenarios, since the browser still believes that it is interacting with the attacker's site, and therefore does not disclose third-party cookies or other sensitive information to the attacker.


차선책(Workarounds)


개발자들이 잘 통제된 상황내에서 동일출처정책을 우회할 수 있도록 하려면, fragment identifier나 window.name 프로퍼티를 사용하는 등 여러가지 편법(hacks)을 사용하여 다른 도메인에 있는 문서간에 데이터를 전달해 왔다. HTML5 표준에서는 이 방법들이 공식화되었다. 바로 postMessage 인터페이스로서 최신 브라우저에서만 사용가능하다. JSONP도 역시 다른 도메인에 Ajax와 비슷한 호출을 활성화시키기 위해 사용될 수 있다.


To enable developers to, in a controlled manner, circumvent the same-origin policy, a number of "hacks" such as using the fragment identifier or the window.name property have been used to pass data between documents residing in different domains. With the HTML5 standard, a method was formalized for this: the postMessage interface,[5][6] which is only available on recent browsers.[7] JSONP can also be used to enable Ajax-like calls to other domains.


=====

제가 기술에 대해 잘 모르기 때문에 공부할 요량으로 번역을 했으나, 그렇기 때문에 정확하지 않을 수 있습니다. 혹시 잘못 이해한 부분이 있다면 댓글로 남겨주시면 감사하겠습니다.


민, 푸른하늘