SOP(Same-origin Policy, 동일 출처 정책)

SOP는 한 출처(origin)에서 로드한 리소스(도큐먼트 또는 스크립트)가 다른 출처에서 로드한 리소스와 상호 작용하는 것을 제한하는 보안 메커니즘이다.

출처(origin)

출처의 구성요소는 다음과 같다.

• 프로토콜
• 호스트
• 포트

동일 출처: 출처의 모든 구성요소가 동일한 출처
교차 출처(또는 다른 출처): 출처의 구성요소가 하나라도 다른 출처

출처 구성요소 예시
http://store.company.com/dir/page.html

• 프로토콜: http
• 호스트: store.company.com
• 포트: 80(http 기본 포트)

다른 URL과 출처 비교 예시

• http://store.company.com/dir2/other.html
  • 같은 출처: 출처의 구성요소가 모두 같다.
• http://store.company.com/dir/inner/another.html
  • 같은 출처: 출처의 구성요소가 모두 같다.
• https://store.company.com/page.html
  • 다른 출처: 프로토콜이 https이다.
• http://news.company.com/dir/page.html
  • 다른 출처: 호스트가 new.company.com이다.
• http://store.company.com:81/dir/page.html
  • 다른 출처: 포트가 81이다.

SOP가 필요한 이유와 CORS

SOP가 없는 경우 다음과 같은 보안 문제가 발생할 수 있다.

• A라는 사람이 어떤 웹사이트(https://cabbage556.com)에 로그인하여 인증 정보인 토큰을 응답 받는다.
• 해커가 'A'가 로그인한 웹사이트와 출처가 비슷한 웹사이트(https://cabage556.com)를 만들고 링크나 이메일을 통해 'A'가 접속하도록 유도한다.
• 'A'는 해커가 비슷하게 만든 웹사이트로 자신의 인증 정보인 토큰을 쿠키에 담아 요청을 보낸다.
• 공격자는 원래 웹사이트(https://cabbage556.com)에 'A'의 토큰을 담아 요청을 보낸다.

하지만 SOP가 존재하기 때문에 공격자의 요청은 거부된다. 사실 이건 CORS와도 관련이 있는데 CORS 정책에 따라 브라우저는 이 요청을 차단한다.

• 다른 출처의 리소스를 요청하는 경우 요청 헤더에 Origin 필드가 담긴 preflight 요청을 실제 요청보다 먼저 보내게 되는데, Origin 필드의 값은 리소스를 요청하는 출처가 담긴다. 이 경우에는 공격자의 출처인 https://cabage556.com 이 담긴다.
• preflight 요청을 받은 서버는 응답을 보낼 때 응답 헤더에 Access-Control-Allow-Origin 필드를 담아 보내는데, Access-Control-Allow-Origin 필드의 값은 해당 리소스를 요청할 수 있는 출처가 담겨 있다. 서버가 이 헤더 필드에 https://cabbage556.com 을 담아 보낸다고 하자.
• preflight 응답을 받은 브라우저는 응답 헤더의 Access-Control-Allow-Origin 필드의 값을 확인하고 Origin 필드의 값과 비교해 다르다면 실제 요청을 보내지 않는다. 이 경우에 서버가 보낸 Access-Control-Allow-Origin 필드의 값과 Origin 필드의 값이 다르기 때문에 브라우저는 실제 요청을 보내지 않고 차단한다.

정리

• SOP는 같은 출처에서 로드된 리소스들끼리만 상호 작용하도록 제한하는 보안 메커니즘이다.
• SOP에 의해 서로 다른 출처에서 로드된 리소스들끼리는 상호 작용할 수 없다.

참고

• Same-origin policy
• CORS는 왜 이렇게 우리를 힘들게 하는걸까?