동일출처정책

Same-origin policy
HTTP
요청 방법
헤더 필드
응답 상태 코드
보안 접근 제어 방법
보안 취약성

컴퓨팅에서, 같은 기원 정책(때로는 SOP로 약칭되기도 한다)은 웹 애플리케이션 보안 모델에서 중요한 개념이다. 이 정책에 따르면, 웹 브라우저는 첫 번째 웹 페이지에 포함된 스크립트가 두 번째 웹 페이지의 데이터에 액세스하도록 허용하지만, 두 웹 페이지의 출처가 같은 경우에만 허용된다. 오리진은 URI 구성표, 호스트 이름 및 포트 번호의 조합으로 정의된다. 이 정책은 한 페이지의 악의적인 스크립트가 다른 페이지의 Document Object Model을 통해 다른 웹 페이지의 중요한 데이터에 액세스하지 못하도록 방지한다.

서버가 HTTP 쿠키 정보에 기초하여 중요한 정보를 공개하거나 상태를 변경하는 조치를 취하기 때문에 인증된 사용자 세션을 유지하기 위해 HTTP 쿠키에[1] 광범위하게 의존하는 현대 웹 애플리케이션에는 이 메커니즘이 특히 중요하다. 데이터 기밀성 또는 무결성의 손실을 방지하기 위해 관련되지 않은 사이트에서 제공하는 컨텐츠 간의 엄격한 분리가 클라이언트 측에서 유지되어야 한다.

동일한 원본 정책이 스크립트에만 적용된다는 것을 기억하는 것은 매우 중요하다. 즉, 이미지, CSS, 동적으로 로드된 스크립트와 같은 자원은 해당 HTML[2] 태그를 통해 원본 전체에 걸쳐 액세스할 수 있다(글꼴이 주목할 만한[3] 예외임). 공격은 HTML 태그에 동일한 오리진 정책이 적용되지 않는다는 점을 이용한다.

역사

동-원래 정책의 개념은 Netscape 2.0에 자바스크립트가 도입된 [4]직후인 1995년에 Netscape Navigator 2.02에 의해 [5][6]도입되었다. 자바스크립트가 웹페이지에서 스크립팅을 가능하게 했고, 특히 DOM(Document Object Model)에 대한 프로그램적 접근을 가능하게 했다.

이 정책은 원래 DOM에 대한 액세스를 보호하기 위해 고안되었지만, 이후 글로벌 자바스크립트 개체의 민감한 부분을 보호하기 위해 확대되었다.

실행

모든 현대의 브라우저는 그것이 중요한 보안의 초석인 것처럼 같은 종류의 동-원 정책을 시행한다.[7] 이 정책은 정확한 규격을[8] 일치시킬 필요는 없지만 Microsoft Silverlight, Adobe Flash 또는 Adobe Acrobat과 같은 다른 웹 기술이나 XMLHtpRequest와 같은 직접 DOM 조작 이외의 메커니즘에 대해 대략적으로 호환되는 보안 경계를 정의하기 위해 확장되는 경우가 많다.

오리진 결정 규칙

URI의 "원점" 계산에 사용되는 알고리즘은 RFC 6454, 섹션 4에 명시되어 있다. 절대 URI의 경우 원본은 트리플 {scheme, host, port}이다. URI가 계층적 요소를 명명 권한으로 사용하지 않거나(RFC 3986, 섹션 3.2 참조) URI가 절대 URI가 아닌 경우 글로벌 고유 식별자가 사용된다. 이 모든 값이 정확히 동일한 경우에만 두 자원이 동일한 것으로 간주된다.

예를 들어, 다음 표는 URL "http://www.example.com/dir/page.html"에 대한 점검에 대한 일반적인 결과에 대한 개요를 제공한다.

비교 URL 결과 이유
http://www.example.com/dir/page2.html 성공 동일한 구성표, 호스트 및 포트
http://www.example.com/dir2/other.html 성공 동일한 구성표, 호스트 및 포트
http://ftp:password@www.example.com/http2/other.pots 성공 동일한 구성표, 호스트 및 포트
http://www.example.com:81/dir/other.html 실패 동일한 구성표 및 호스트 그러나 다른 포트
https://www.example.com/dir/other.html 실패 다른 방식
http://en.example.com/dir/other.html 실패 다른 호스트
http://example.com/dir/other.html 실패 다른 호스트(정확한 일치 필요)
http://v2.www.example.com/dir/other.html 실패 다른 호스트(정확한 일치 필요)
http://www.example.com:80/dir/other.html 경우에 따라 다르지요 좌현 명시. 브라우저의 구현에 따라 다름.

다른 브라우저와 달리 Internet Explorer(인터넷 익스플로러)[9]는 보안 영역을 제자리에 사용하여 오리진 계산에 포트를 포함하지 않는다.

재사용 가능한 인증을 통해 중요한 상호 원본 응답에 대한 읽기 액세스

동일한 원본 정책은 원본 간에 인증된 세션을 재사용하는 것을 방지한다. 다음 사례는 동일한 원산지 정책 없이 발생할 수 있는 잠재적 보안 위험을 예시한다. 사용자가 은행 웹 사이트를 방문하고 로그아웃하지 않는다고 가정해 보십시오. 그런 다음 사용자는 은행 사이트에서 데이터를 요청하는 악의적인 자바스크립트 코드가 있는 다른 사이트로 이동한다. 사용자가 여전히 은행 사이트에 로그인하고 있기 때문에, 악성 코드는 사용자가 은행 사이트에서 할 수 있는 모든 것을 할 수 있다. 예를 들어, 사용자의 마지막 거래 목록을 얻을 수 있고, 새로운 거래를 만들 수 있다. 월드 와이드 웹의 본래의 정신에서, 브라우저가 세션 쿠키나 플랫폼 수준의 권한 부여 요청 헤더 등의 인증 세부사항을 따라 은행 사이트의 도메인을 기반으로 하는 은행 사이트에 태그해야 하기 때문이다.

은행 사이트 소유자들은 악성 사이트를 방문하는 사용자들의 정기적인 브라우저가 악성 사이트에서 로드된 코드가 은행 세션 쿠키나 플랫폼 수준의 권한에 액세스하지 못하게 할 것으로 예상한다. 자바스크립트는 은행 세션 쿠키에 직접 접근할 수 없는 것은 사실이지만, 은행 사이트의 세션 쿠키로 은행 사이트에 요청을 주고받을 수도 있다. 같은 오리진 정책은 보안에 민감한 브라우저가 대다수의 사용자가 호환 브라우저를 사용하기로 선택한다는 가정 하에, 발신지 전체에 걸친 응답에 대한 읽기 액세스를 거부하도록 하는 요구조건으로 도입되었다. 그 정책은 쓰기를 거부하지 않는다. 쓰기 허가 남용을 대응하려면 대상 사이트에 의한 추가적인 CSRF 보호가 필요하다.

동일 근원 정책 완화

어떤 상황에서는 동일한 원본 정책이 너무 제한적이어서 여러 하위 도메인을 사용하는 대형 웹 사이트에 문제를 제기하기도 한다. 처음에는 단편 식별자 또는 단층 식별자 사용과 같은 여러 가지 해결책이 있다. window.name 속성은 서로 다른 도메인에 있는 문서들 사이에 데이터를 전달하기 위해 사용되었다. 현대의 브라우저는 통제된 방식으로 동일한 오리진 정책을 완화하기 위한 여러 가지 기법을 지원한다.

데이터 태인화

Netscape Navigator는 간략하게 색칠된 확인 기능을 포함했다. 이 특징은 넷스케이프 3의 일부로 1997년에 실험적으로 도입되었다.[10] 이 기능은 기본적으로 꺼져 있었지만 사용자에 의해 활성화되면 웹 사이트가 다른 도메인에 속한 창과 프레임의 자바스크립트 속성을 읽으려고 시도할 수 있다. 그러면 브라우저는 사용자에게 문제의 액세스를 허용할 것인지 여부를 묻게 된다.[11][12]

document.domain 속성

두 창(또는 프레임)에 도메인을 동일한 값으로 설정하는 스크립트가 포함된 경우, 이 두 창에 대해 동일한 원본 정책이 완화되고 각 창은 다른 창과 상호 작용할 수 있다. 예를 들어, orders.example.com과 catalog.example.com에서 로드된 문서의 협력 스크립트는 다음 스크립트를 설정할 수 있다. document.domain "example.com"의 등록 정보로, 따라서 문서의 출처가 같아 보이고 각 문서가 다른 문서의 등록 정보를 읽을 수 있게 된다. 이 속성을 설정하면 대부분의 브라우저가 포트 80 또는 지정되지 않은 포트와 다르게 해석되는 포트를 암시적으로 null로 설정한다. 브라우저에서 액세스가 허용되도록 하려면 두 페이지의 document.domain 속성을 설정하십시오.[13]

그 document.domain 개념은 1996년에 출시된 Netscape Navigator 3의 일부로 도입되었다.[14][10]

크로스 오리진 리소스 공유

동일한 오리진 정책을 완화하는 다른 기법은 CORS(Cross-Origin Resource Sharing)라는 이름으로 표준화된다. 이 표준은 새로운 오리진 요청 헤더와 새로운 액세스-제어-허용-오리진 응답 헤더를 사용하여 HTTP를 확장한다.[15] 그것은 서버가 파일을 요청할 수 있는 원본을 명시적으로 나열하거나 와일드카드를 사용할 수 있도록 하며 어떤 사이트에서도 파일을 요청할 수 있도록 허용한다. Firefox 3.5, Safari 4 및 Internet Explorer 10과 같은 브라우저에서는 이 헤더를 사용하여 XMLHtpRequest를 사용하는 교차 오리진 HTTP 요청을 허용하며, 그렇지 않으면 동일한 오리진 정책에 의해 금지되었을 것이다.

교차 문서 메시징

또 다른 기술인 교차 문서 메시징은 한 페이지의 스크립트가 스크립트 원점에 관계없이 다른 페이지의 스크립트로 텍스트 메시지를 전달할 수 있도록 한다. 창 개체의 postMessage() 메서드를 호출하면 해당 창에서 "onmessage" 이벤트가 비동기적으로 발생하여 사용자 정의 이벤트 핸들러를 트리거한다. 한 페이지의 스크립트는 여전히 다른 페이지의 방법이나 변수에 직접 접근할 수 없지만, 그들은 이 메시지 전달 기법을 통해 안전하게 의사소통을 할 수 있다.

제이슨프

주요기사 : JSONP

HTML 이후 <script> 요소는 다른 도메인에서 콘텐츠를 검색하고 실행할 수 있도록 허용되며, 페이지는 JSONP 페이로드를 반환하는 리소스를 로드하여 동일한 원본 정책을 무시하고 다른 도메인에서 JSON 데이터를 수신할 수 있다. JSONP 페이로드(payloads)는 미리 정의된 함수 호출에 의해 포장된 내부 JSON 페이로드로 구성된다. 브라우저가 스크립트 리소스를 로드하면 지정된 콜백 기능이 호출되어 래핑된 JSON 페이로드를 처리한다.

웹소켓

주요 기사: 웹소켓

현대 브라우저에서는 동일한 원본 정책을 적용하지 않고 스크립트가 WebSocket 주소에 연결할 수 있도록 허용한다. 그러나 WebSocket URI가 사용되는 시기를 인식하고 연결을 요청하는 스크립트의 원본을 나타내는 요청에 원본: 헤더를 삽입한다. 사이트 간 보안을 보장하기 위해 WebSocket 서버는 헤더 데이터를 회신을 수신할 수 있는 원본 화이트리스트와 비교해야 한다.

코너 케이스

URL(파일:, 데이터: 등)과 관련하여 명확하게 정의된 호스트 이름이나 포트가 없는 사이비 프로토콜과 같은 여러 코너 사례에서 동일한 오리진 점검 및 관련 메커니즘의 동작이 잘 정의되지 않는다. 이는 역사적으로 디스크의 다른 모든 파일에 접근하거나 인터넷 상의 어떤 사이트와 통신하는 로컬로 저장된 HTML 파일의 바람직하지 않은 기능과 같은 상당한 수의 보안 문제를 야기했다.

마지막으로 DNS 재 바인딩이나 서버측 프록시와 같은 특정 유형의 공격은 호스트 이름 검사가 부분적으로 하위 변환되도록 허용하며, 악성 웹 페이지가 "참"인 표준 원점이 아닌 다른 주소를 통해 사이트와 직접 상호 작용할 수 있도록 한다. 이러한 공격의 영향은 브라우저가 여전히 공격자의 사이트와 상호작용을 하고 있다고 믿고 있기 때문에 매우 구체적인 시나리오로 제한되며, 따라서 공격자에게 제3자 쿠키나 기타 민감한 정보를 공개하지 않는다.

동일 근원 정책 앞에서의 공격

(크로스 오리진 리소스 공유에 의해 완화되지 않고) 동일한 오리진 정책이 시행되는 경우에도 특정 오리진 간 컴퓨터 공격을 수행할 수 있다. WebRTC는 희생자의 내부 IP 주소를 알아내는 데 사용될 수 있다.[16] 크로스 오리진 포트에 연결을 시도할 경우, 동일한 오리진 정책 앞에서 응답을 읽을 수 없지만, JavaScript는 onload/onerror 이벤트가 발생하는지 또는 시간 초과가 발생하는지 확인하여 포트 개방 또는 닫힘 여부를 여전히 추론할 수 있다. 이것은 크로스 오리진 포트스캔을 위한 기회를 제공한다. 또한, 자바스크립트는 기본 파일을 이용하여 교차 오리진 서비스를 지문 채취할 수도 있다. 예를 들어 사이트 evil.com에서 로드된 자바스크립트가 http:///1987.0.1/messages/messages.png 파일을 열려고 시도하고 온로드 이벤트가 발생하면 피해자가 젠킨스를 자신의 컴퓨터로 실행한다고 추론할 수 있다. 이러한 방식으로 공격자는 예를 들어 내부 네트워크에서 같은 오리진 정책에 직면하더라도 잠재적으로 취약한 서비스를 찾을 수 있다. 만약 어떤 서비스가 사이트 간 요청 위조에 취약하다면, 그것들은 심지어 손상될 수도 있다.[17]

참고 항목

추가 읽기

참조

  1. ^ IETF HTTP 상태 관리 메커니즘, 2011년 4월
  2. ^ Kemp, John (2011-02-04). "Security on the Web". Retrieved 2018-07-24. The same-origin policy states that a document from one unique origin may only load resources from the origin from which the document was loaded. In particular this applies to XMLHttpRequest calls made from within a document. Images, CSS and dynamically-loaded scripts are not subject to same-origin policy.
  3. ^ "@font-face". MDN Web Docs. Retrieved 2021-07-24. Web fonts are subject to the same domain restriction (font files must be on the same domain as the page using them), unless HTTP access controls are used to relax this restriction.
  4. ^ "Netscape 3.0 Handbook - Advanced topics". netscape.com. Archived from the original on 2002-08-08. Retrieved 2020-02-16. Navigator version 2.02 and later automatically prevents scripts on one server from accessing properties of documents on a different server.
  5. ^ "JavaScript 1.0 - 1995". www.webdesignmuseum.org. Retrieved 2020-01-19.
  6. ^ "Welcome to Netscape Navigator Version 2.0". netscape.com. 1997-06-14. Archived from the original on 1997-06-14. Retrieved 2020-02-16.
  7. ^ "Browser Security Handbook, part 2". google.com. Retrieved 31 January 2014.
  8. ^ "Same Origin Policy". W3C. Retrieved 31 January 2014.
  9. ^ Lawrence, Eric. "IEInternals - Same Origin Policy Part 1". Retrieved 22 October 2013.
  10. ^ a b "Netscape Navigator 3.0 - What's New". netscape.com. 1997-06-14. Archived from the original on 1997-06-14. Retrieved 2020-02-16.
  11. ^ "JavaScript 1.3 Guide - Security". netscape.com. 2003-02-21. Archived from the original on 2003-02-21. Retrieved 2020-02-16.
  12. ^ "JavaScript 1.3 Guide - Security". docs.oracle.com. Archived from the original on 2012-08-24. Retrieved 2020-02-16.
  13. ^ LePera, Scott. "Cross-domain security woes". The Strange Zen Of JavaScript. Retrieved 4 April 2014.
  14. ^ "Netscape 3.0 - JavaScript Handbook". netscape.com. Archived from the original on 2002-10-03. Retrieved 2020-02-16.
  15. ^ WSGI 미들웨어 만들기
  16. ^ JavaScript를 사용하여 내부 IP 주소 검색
  17. ^ 브라우저를 프록시로 사용하여 공용 인터넷에서 내부 네트워크 공격

외부 링크