[Network] Same-Origin Policy

Bik_Kyun·2022년 3월 13일
0
post-thumbnail

1. 동일 출처 정책

어떤 출체에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식.
잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여준다. -MDN

어떠한 문서나 스크립트가 다른 프로토콜/포트/호스트 에 있는 리소스를 사용하는 것을 제한하는 정책.

예를들어,
http://kims.shop.com:80/doc/page.html
이 URL과 비교해 Same-Origin URL들을 구분해보면

비교 URL동일 출처내용
http://kims.shop.com/public/test.htmlO다른 경로(성공)
http://kims.shop.com/doc/temp/index.htmlO다른 경로(성공)
https:// kims.shop.com/doc/page.htmlX다른 프로토콜(실패)
http://kims.shop.com :81 /doc/page.htmlX다른 포트(실패)
http:// parks .shop.com/doc/page.htmlX다른 호스트(실패)

이처럼 호스트, 포트, 프로토콜 중 하나라도 다르면 동일 출처 정책이 적용되어 요청에 실패한다.

2. 사용 이유

  • 데이터 기밀 유지, 관계없는 사이트에서 제공된 콘텐츠는 클라이어트단에서 차단
  • 현대 웹 어플리케이션은 authenticated된 사용자의 세션을 유지하기 위해 cookie에 의존하기 때문
  • 웹 어플리케이션이 authorised된 사용자의 세션 정보를 cookie에 담아 광범위하게 사용하는 경우, 출처가 다른 페이지에서 스크립트를 이용해 해당 쿠키정보를 추출할 수 있기 때문.
  • 스크립트 삽입을 통한 잠재적 XSS공격 차단

이런 이유로 대부분의 브라우저가 동일 출처 정책을 따른다. 그런데,

⚠️ Internet Exploler 예외사항
동일 출처 정책은 브라우저에서 동작하는 제약이므로 브라우저마다 상이하게 적용될 수 있다.
1) 신뢰할 수 있는 사이트 : 양쪽 도메인 모두 '높음'단계의 보안 수준인 경우 동일 출처 제약을 적용하지 않는다.
2) 포트 : 포트 검사를 하지 않는다. Internet Explorer에서 URL의 포트만 다른 경우에는 동일 출처로 간주된다.

3. 동일 출처 정책 범위

동일 출처 정책은 스크립트에만 적용된다. 이미지, CSS나 동적으로 로딩된 스크립트들은 그에 대응하는 HTML 태그(img, video, embed, iframe)등을 사용함으로써 교차 출처가 허용된다.

부록) CSRF공격

동일 출처 정책은 cross-site 읽기만 방어할 뿐, 쓰기를 예방하지 못한다. 동적으로 로딩된 스크립트가 어떤 요청을 보내는 것을 막을 수 없다. cross-site가 사용자의 인증 정보가 담긴 쿠키를 이용해 서버에 있는 정보를 탈취하려 한다면 서버에서 SameSite 쿠키 설정으로 이를 예방할 수 있다.

4. 동일 출처 정책 피하기

1) document.domain

동일한 도메인으로 설정함으로써 SOP 정책을 피할 수 있다.
만약 도메인이 http://kims.shop.com/page.html라고 할때,

document.domain = "shop.com";

이렇게 설정하면 http://shop.com/page.html에 요청을 보낼 수 있다. 단, html파일에 관련된 모든 스크립트 파일에 위와 같이 설정해야하며 Firefox에서는 적용되지 않는다. 또한, 서버-클라이언트 통신에 쓰이는 방법이 아니라 클라이언트 상에서 출처가 다른 프레임들에 대해 쓰인다.(서버와 통신은 불가능하다는 말)

2) window.postMessage

프레임에서 사용하는 개념.
페이지에서 프레임으로 문자열 값을 보낼 수 있고 받는 프레임에선 이벤트 핸들러를 통해 받을 수 있다.

3) 프록시 서버

프록시 서버는 클라이언트와 서버 사이에서 정보교환을 도와주는 서버이다.
리소스를 요청하고자 하는 서버의 Access-Control-Allow-Origin속성을 수정할 수 없는 경우 유용하다. 실제 서버에서 요청을 보내서 받아온 결과를 프록시 서버가 Access-Control-Allow-Origin설정을 적절히 만져 클라이언트에게 보여주는 방식이다.
서버를 한 단계 더 거치기 때문에 기존의 요청보다 느리다는 단점이 있다.

4) JSONP(JSON with Padding)

CORS가 나오기 이전에 사용하던 방식.
<script>태그를 사용하면 SOP정책을 피할 수 있기 때문에 JSON 데이터를 받아올 때 사용했다.
최신 브라우저에서는 거의 사용하지 않고 보안 문제가 있기 때문에 CORS를 권장한다.

5) CORS

는 따로 정리

profile
비진

0개의 댓글