모든 내용은 RFC-6454[2] 의 내용을 요약한 것이다.
단어 정리
-
user-agent : 자료를 요청하는 클라이언트로 브라우저나, 에디터, 다른 유저가 사용하는 툴에 해당 한다. 이번 글에서는 브라우저를 유저 에이전트로 칭한다.
-
URI : Uniform-Resource-Identifier 의 약자로 네트워크에서 자원을 식별하는데 사용 되는 용어로 자원의 위치 뿐 아니라 다양한 속성을 포함하여 자원을 고유하게 식별한다.
-
origin-server : 리소스를 생성하거나 저장하는 서버를 의미 한다.
모든 단어 정의는 RFC-2616 [2] 에서 정의 되었다.
브라우저의 정보 교환은 URI 기반
유저 에이전트가 다양한 서버와 정보 교환을 위해 사용하는 요소는 'URI' 이다.
html, img, script, css .. 등 다양한 정보는 uri 를 기반으로 하여 오리진 서버에 요청을 보내 리소스를 제공 받는다.
// 스크립트 파일을 받아와 실행하거나
<script src="https://example.com/library.js"></script>
// 민감한 정보를 담아 오리진 서버에 데이터를 생성한다.
<form method="POST" action="https://example.com/login">
... <input type="password"> ...
</form>SOP (Same Origin Policy)
SOP는 신뢰하는 URI에서만 리소스 교환이 일어나도록 하는 정책이다.
신뢰하는 URI란 기본적으로 오리진 서버와 유저 에이전트의 주소가 같은 것을 의미 한다.
여기서 말하는 origin 이란 ?
origin 이란 URI를 이루는 스킴, 호스트, 포트를 그룹화 한 단위이다.
예를 들어 다음 같은 경우는 같은 origin 이다.
http://example.com/
http://example.com:80/
http://example.com/path/file스킴 (http), 호스트 (example.com) , 포트 (80) 이 같기 때문이다.
다음과 같은 경우는 모두 다른 origin 이다.
http://example.com/
http://example.com:8080/
http://www.example.com/
https://example.com:80/
https://example.com/
http://example.org/
http://ietf.org/서로 스킴, 호스트, 포트가 서로 다르기 때문이다.
스킴, 호스트, 포트를 한 단위로 origin 으로 묶는 이유는
오리진 서버를 찾기 위한 DNS 는 계층적으로 스킴, 호스트, 포트를 순회하여 오리진 서버를 찾기 때문이다.
세 개 중 하나라도 다르면 DNS는 서로 다른 오리진 서버의 주소를 제공한다.
SOP가 등장한 이유
유저 에이전트가 존재하는 URL에서는 다양한 URI 에서 얻어진 리소스등으로 이뤄져 있는 복잡한 dom 으로 구성된 문서를 받아 볼 수 있다.
이는 서버가 다양한 리소스들을 직접적으로 들고 있을 필요 없이 다양한 리소스를 활용 할 수 있기에 장점으로 적용했지만
가끔씩은 악의적인 목적을 가져 보안을 위협하는 리소스 등이 존재 할 수 있다.
예를 들어 유저 에이전트의 쿠키나 세션 정보를 탈취하는 스크립트나 직접 유저 에이전트의 돔을 조작하는 스크립트를 삽입하는 Cross-Site-scripting 이나
유저 에이전트가 다른 오리진 서버로 요청을 보내게 하는 스크립트를 삽입하는 Cross-Site Request Forgery 등이 있다.
이렇게 유저 에이전트가 존재하는 URL과 다른 URI 의 리소스를 무작정 모두 허용하게 되면 보안에 큰 위험을 초래 할 수 있다.
이에 기본적으로 브라우저는 유저 에이전트에게 문서를 제공한 오리진 서버와 같은 오리진을 갖는 리소스들만 정보를 교환 할 수 있게 하는 SOP 를 기본으로 지킨다.
그렇다면 모든 리소스가 SOP 를 지켜야하나 ?
3.3. Authority
Although user agents group URIs into origins, not every resource in
an origin carries the same authority (in the security sense of the
word "authority", not in the [RFC3986] sense). For example, an image
is passive content and, therefore, carries no authority, meaning the
image has no access to the objects and resources available to its
origin. By contrast, an HTML document carries the full authority of
its origin, and scripts within (or imported into) the document can
access every resource in its origin.User agents determine how much authority to grant a resource by
examining its media type. For example, resources with a media type
of image/png are treated as images, and resources with a media type
of text/html are treated as HTML documents.When hosting untrusted content (such as user-generated content), web
applications can limit that content's authority by restricting its
media type. For example, serving user-generated content as image/png
is less risky than serving user-generated content as text/html. Of
course, many web applications incorporate untrusted content in their
HTML documents. If not done carefully, these applications risk
leaking their origin's authority to the untrusted content, a
vulnerability commonly known as cross-site scripting
출처 : https://datatracker.ietf.org/doc/html/rfc6454#section-3.4.3
이미지나 텍스트와 같은 passive content 의 경우에는 서로 다른 오리진이더라도 특별한 권한 없이 정보를 요청하는 것이 가능하다.
스크립트와 같은 active content 보다 위험성이 적기 때문이다.
CORS (Cross Origin Resource Sharing)
cors 는 서로 다른 오리진에서 정보를 주고 받기 위한 HTTP 프로토콜의 일부이다.
오리진 서버 입장에서 특정 리소스의 URI 에서 허용된 출처 (Allowed Origin) 를 헤더의 Access-Control-Allow-Origin 영역에 특정함으로서
오리진 서버의 URI 외에도 헤더에서 정의 한 URI에서 리소스를 주고 받는 것을 가능하게 한다. [3]
출처
