SOP와 CORS 개념

SOP

SOP(Same-origin policy)는 웹 브라우저에 내장된 보안 정책으로서 동일한 origin을 보유한 리소스만 

접근 가능하도록 제한한다. origin은 도메인과 다르게 호스트뿐만 아니라 포트와 스키마까지 추가된 개념이다.

개발자 도구 콘솔에서 origin을 조회하면 현재 접속된 사이트의 origin을 알아낼 수 있다.
브라우저는 origin을 취급할 때 스키마(https), 호스트(www.naver.com), 포트(443)를 보고 판단한다.
저 요소 중 하나라도 다르면 동일한 origin이 아닌 것이다.
만약 네이버에서 네이버 자료를 본다면 그것은 동일한 origin에 해당되어 리소스 접근이 허용되지만
내가 접속한 사이트에서 다른 Origin에 요청하면 SOP에 의해 차단된다.

SOP가 동작하지 않는다면 다음과 같은 CSRF 공격 시나리오가 가능하다.
① <iframe src="http://mail.naver.com" width="0" height="0"></iframe>
공격자는 상대방의 메일 정보를 탈취하기 위해 abc.com 사이트에 네이버 메일로 접속하는 iframe 태그를 삽입한다.

② 피해자가 abc.com 사이트에 접속했을 때 네이버에 로그인되어 있다면 피해자의 브라우저에 저장된 쿠키로 인해 자동적으로 로그인되어 iframe에서 네이버 메일로 접속된다. iframe 크기는 0이므로 피해자는 해킹 사실을 인지하지 못한다.

③ SOP가 존재한다면 abc.com과 mail.naver.com이 다른 origin이므로 mail.naver.com을 읽지 못한다.
하지만 SOP가 없다면 저 메일을 그대로 읽어들여 공격자 서버로 전송하게 된다.

웹 브라우저는 SOP가 적용되기 때문에 상위 문서에서 iframe 내부의 문서를 참고하게 될 때 

orgine이 다르므로 참조할 수 없다.  따라서 이러한 해킹 공격을 방어할 수 있다.

CORS

웹 사이트를 개발하다보면 api 서버를 많이 사용하게된다. API 서버와 웹사이트간 데이터를 주고받아야 하는데
도메인이 서로 달라서 SOP 정책에 의해 차단되면 데이터를 읽어드릴 수 없다.
이때 CORS(Cross-Origin Resource Sharing)를 통해 다른 origin을 가진 리소스에 자원을 read 할 수 있다.
예를들어 CORS가 허용되면 구글에서 네이버로 전달한 데이터를 읽어들이는게 가능해진다.
참고로 네트워크 API를 사용해서 다른 서버에 자원 요청할 때 전송(write)하는 것은 same-origin이든
cross-orgin이든 일반적으로 가능하다. 대신 이 요청이 preflight일 때는 전송도 할 수 없다.

➽ preflight
요청을 보내기 전 파일 서비스에 대한 규칙을 질의하는 쿼리.

ி CORS 정책 허용

CORS 기본 정책은 거부로 설정되어 있다. 이를 승인하려면 서버에서 직접 허용 설정을 해야한다.
CORS 통신이 필요할 때 모든 origin을 대상으로 SOP를 무력화하는 JSONP을 이용할 수도 있는데
이는 비표준적인 방법이라서 보안에 취약하므로 사용을 금하고 있다.
W3C에서는 CORS를 허용하는 표준적인 방법을 제시한다.
허용할 origin을 ACAO(Access-Control-Allow-Origin)에 추가하면 요청한 데이터를 읽을 수 있다.

테스트를 위해 jsp 웹 애플리케이션을 2개 생성하고 포트 8080과 8081로 설정한다.
그리고 8080에서 8081로 json 데이터를 요청했을 때 웹 브라우저에 어떤 반응이 나타나는지 확인한다.



8081 서버에서 ACAO를 허용하지 않았기 때문에 아래처럼 CORS policy 문제가 발생한다.

8081 서버에서 8080 서버의 접근을 허용하는 코드를 작성한다.

허용할 origin을 ACAO에 추가하면 cross-origin으로 요청해도 위와 같이 데이터를 정상적으로 읽을 수 있다.