Mitigation: Same Origin Policy

---

Mitigation: Same Origin Policy

SOP에 대하여

이전까지의 쿠키와 세션에 관한 내용은 기본적이라서 저의 정리보단 직접 배우면서 하는게 좋아보여서..
사실 귀찮아서가 제일 큰데 ㅋㅋ

웹의 이해와 HTTP

 

쿠키와 세션

여기 링크를 통해 꼭 학습해봅시다! 아래 링크 들어가서 문제도 하시고
쿠키 & 세션

 

바로 SOP에 대하여 배워봅시다.

---

쿠키에는 인증 상태를 나타내는 민감한 정보가 보관되며, 브라우저 내부에 저장됩니다.
그리고 브라우저가 웹 서비스에 접속 시 자동으로 쿠키를 헤더에 포함해 요청을 보내죠

 

이 덕분에 우리는 웹 서비스에 한 번 로그인 후 일정 기간은 로그인 없이 바로 서비스를 사용할 수 있는거죠
그러나 만약 이용자가 악의적인 목적으로 악의적인 페이지를 접속 시 어떻게 될까요?

SOP(Same Origin Policy) 탄생 배경

악의적인 페이지 접속 → 만약 JS 이용 이용자의 SNS 웹 서비스로 요청 시..
→ 브라우저는 요청 보낼 때 해더에 해당 웹 서비스 쿠키를 포함시킴..


 따라서 JS로 요청을 보낸 페이지는 로그인 된 이용자의 SNS 응답을 받음
그래서 세션 하이제킹 같은 문제가 발생할 수 있습니다.

SOP 즉, 동일 출처 정책은 클라이언트 사이드 웹 보안에 있어 중요한 요소입니다.
실제로 클라이언트 사이드 공격(XSS)은 이 SOP를 우회하기 위해도 과언이 아닙니다.
어떻게 자동하고 예외 상황은 뭐인지 자세하게 알아봅시다.

---

Same Origin Policy (SOP)

서론의 예시처럼 브라우저는 인증 정보로 사용될 수 있는 쿠키를 브라우저 내부에 보관하며 또한
이용자가 웹 서비스 접속 시, 브라우저는 해당 웹 서비스에 사용되는 인증 정보 쿠키를 http요청 포함

 

이 특징은 사이트에 직접 접속하는 것에만 한정 X
브라우저는 웹 리소스를 통해 간접적으로 타 사이트에 접근 시에도 인증 정보 쿠키를 함께 전송함

이 특징 땜에 악의적 페이지가 클라이언트의 권한을 이용해
대상 사이트에 해더 요청을 보내 응답 정보를 획득하는 코드를 실행

이는 정보 유출과 같은 보안 이슈로 클라이언트 입장에서 가져온 데이터를 악의적 페이지가
못 읽게 해야겠죠 그래서 나온 브라우저의 보안 메커니즘인 SOP입니다.

---

Same Origin Policy의 Origin 구분 방법

이제 브라우저가 가져온 정보인 오리진(Origin)을 어떻게 구분할까요?
먼저 오리진은 프로토콜(Protocol, Scheme), 포트(Port), 호스트(Host)로 구성됩니다.

 

구성 요소가 모두 일치해야 동일한 오리진이라고 합니다.
https://same-origin.com/ 라는 오리진과 아래 URL을 비교했을 때 결과는 다음과 같습니다.

---

위와 같이 비교해서 확인한답니다!

---

Same Origin Policy 실습

SOP는 Cross Origin이 아닌 Same Origin일 때만 정보를 읽을 수 있도록 해줍니다.
예시로 아래 이미지가 있으며 JavaScript의 이용해 SOP를 테스트 하네요

 

여기서 window.open은 새 창 띄우는 함수, object.location.href는 객체가 가르킨 URL 주소 읽는 코드

이제 개발자 도구를 켜서 실습해보세요 해당 결과창은 직접해보시면서 확인해보세요
그러시면 왤케 성의가 없냐.. 라고 하면 이건 부전공이기에 상세히 세밀하게 하긴.. 힘들어서요 ㅠ

---

Same Origin Policy(SOP) 데모

지금까지 SOP가 무엇인지 알아봤고 구분까지 배웠습니다.
이제 다음 모듈 구성으로 실습해보기 전에 살펴봅시다.

<!-- iframe 객체 생성 -->
<iframe src="" id="my-frame"></iframe>
 
<!-- Javascript 시작 -->
<script>
/* 2번째 줄의 iframe 객체를 myFrame 변수에 가져옵니다. */
let myFrame = document.getElementById('my-frame')
 
/* iframe 객체에 주소가 로드되는 경우 아래와 같은 코드를 실행합니다. */
myFrame.onload = () => {
    /* try ... catch 는 에러를 처리하는 로직 입니다. */
    try {
        /* 로드가 완료되면, secret-element 객체의 내용을 콘솔에 출력합니다. */
        let secretValue = myFrame.contentWindow.document.getElementById('secret-element').innerText;
        console.log({ secretValue });
    } catch(error) {
        /* 오류 발생시 콘솔에 오류 로그를 출력합니다. */
        console.log({ error });
    }
}
 
/* iframe객체에 Same Origin, Cross Origin 주소를 로드하는 함수 입니다. */
const loadSameOrigin = () => { myFrame.src = 'https://same-origin.com/frame.html'; }
const loadCrossOrigin = () => { myFrame.src = 'https://cross-origin.com/frame.html'; }
</script>
 
<!--
버튼 2개 생성 (Same Origin 버튼, Cross Origin 버튼)
-->
<button onclick=loadSameOrigin()>Same Origin</button><br>
<button onclick=loadCrossOrigin()>Cross Origin</button>
 
<!--
frame.html의 코드가 아래와 같습니다.
secret-element라는 id를 가진 div 객체 안에 treasure라고 하는 비밀 값을 넣어두었습니다.
-->
 
<div id="secret-element">treasure</div>

---

코드 동작 설명

1.  두번 줄의 iframe 현재 웹 페이지 안에 또 다른 웹 페이지 삽입하는 HTML 태그
   src 요소를 설정함으로써 삽입할 웹 페이지의 주소가 결정됨!
   
   
2.  열번째 줄의 onload 이벤트 핸들러로, 해당 객체가 성공적 로드 시 동작
   본 예시엔 10-24번 줄이 iframe 객체의 페이지가 로드 시 동작되는 코드!
   
   
3.  14-15번째 줄은 로드 완료 시 iframe 내에 삽입된 주소 secret-element 객체의 값인
   treasure를 읽어와 콘솔에 출력하는 동작 수행!

근데 사실 위 코드의 내용은 Dreamhack 로드맵에서 실습 웹 페이지의 코드라서.. 딱히
성공과 실패의 모습만 이미지로 보여드릴께요 ㅠ

왼쪽은 성공 오른쪽은 실패

위 웹은 SOP에서 iframe에 Same Origin이 아닌 Cross Origin을 넣으면
세번째 동작 과정이 실패로 출력됩니다. 그 이유는 위에 코드 보시면 되겠죠?

---

Same Origin Policy 제안 완화

SOP는 클라이언트 사이드 웹 보안에서 중요한 요소입니다.
하지만, 브라우저가 이러한 SOP에 구애 받지 않고 외부 출처에 대한 접근을 허용하는 경우도 있죠

 

예를 들면, 이미지나 JS, CSS 등의 리소스를 불러오는 <img>, <style>, <script> 등의 태그가 있죠

 

위 경우들 외에도 웹 서비스에 SOP를 완화하여 다른 출처의 데이터를 처리 해야 하는 경우도 있습니다.
예로 특정 포털 사이트 카페, 블로그 등의 주소로 운영 시 각 서비스 Host가 다르니까 오리진이 다르겠죠?

• 카페: https://cafe.dreamhack.io
• 블로그: https://blog.dreamhack.io
• 메일: https://mail.dreamhack.io
• 메인: https://dreamhack.io

위는 Theori의 회사측에서.. 음 Dreamhack 부속 사이트들의 예제인듯 싶네요 쨋든

 

이러한 환경에서, 이용자가 수신한 메일의 개수를 메인 페이지에 출력할려면 SOP를 허락해야 합니다.
이 때, 두 사이트는 오리진이 다르므로 SOP를 적용받지 않고 리소스를 공유할 방법이 요구됨!

 

그래서 교차 출처 리소스 공유(Cross Origin Resource Sharing; CORS)라고 합니다.
공유 방법은 CORS와 관련된 HTTP 해더를 추가하여 전송하는 방법을 사용합니다.
그 외에도 JSON with Padding(JSONP) 방법도 있습니다

---

Cross Origin Resource Sharing(CORS)

CORS는 HTTP 해더 기반 Cross Origin 간의 리소스를 공유하는 방법입니다.
발신측에 CORS 해더를 설정해 요청 시, 수신측은 헤더를 구분해 정해진 규칙에 의해 데이터 공유!

 

아래 두 이미지는 각각 웹 리소스를 요청하는 발신측 코드의 일부와 발신측의 HTTP요청입니다.

웹 리소스 요청 코드

/*
    XMLHttpRequest 객체를 생성합니다. 
    XMLHttpRequest는 웹 브라우저와 웹 서버 간에 데이터 전송을
    도와주는 객체 입니다. 이를 통해 HTTP 요청을 보낼 수 있습니다.
*/
 
xhr = new XMLHttpRequest();

/* https://theori.io/whoami 페이지에 POST 요청을 보내도록 합니다. */
xhr.open('POST', 'https://theori.io/whoami');

/* HTTP 요청을 보낼 때, 쿠키 정보도 함께 사용하도록 해줍니다. */
xhr.withCredentials = true;

/* HTTP Body를 JSON 형태로 보낼 것이라고 수신측에 알려줍니다. */
xhr.setRequestHeader('Content-Type', 'application/json');

/* xhr 객체를 통해 HTTP 요청을 실행합니다. */
xhr.send("{'data':'WhoAmI'}");

발신측의 HTTP 요청

OPTIONS /whoami HTTP/1.1
Host: theori.io
Connection: keep-alive
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Origin: https://dreamhack.io
Accept: */*
Referer: https://dreamhack.io/

그럼 입력받은 해더의 대한 정보에 대하여 알아가보며 확인해봅시다.

 

표를 살펴보면, 발신측에서 POST방식으로 HTTP 요청을 보냈으나,
OPTIONS 메소드를 가진 HTTP 요청이 전달된 것을 확인할 수 있습니다.

 

이를 CORS preflight라고 하며, 수신측에 웹 리소스를 요청해도 되는지 질의하는 과정!
그리고 위에 2번째 코드를 보시면 "Access-Control-Request"로 시작하는 헤더가 존재합니다

 

해당 헤더 뒤에 따라오는 Method와 Headers는 각 메소드와 헤더를 추가적으로 사용할 수 있는지 질의함!
또한 위처럼 질의 시 서버는 아래와 같이 응답하며, 다음은 응답 결과에 대한 설명입니다.

서버의 응답

OPTIONS /whoami HTTP/1.1
Host: theori.io
Connection: keep-alive
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Origin: https://dreamhack.io
Accept: */*
Referer: https://dreamhack.io/

---

이해 자료

위 과정을 마치면 브라우저는 수신측의 응답이 발신측의 요청과 상응한가 확인하고,
그때야 비로소 POST 요청을 보내 수신측의 웹 리소스를 요청하는 HTTP 요청을 보냄

---

JSON with Padding(JSONP)

아까 이미지, JS, CSS 등의 리소스는 SOP에 구애 X, 외부 출처 접근 허용한다고 했죠

 

JSONP 방식은 이러한 특징 활용 <script> 태그로 Cross Origin의 데이터를 호출
하지만 <script> 태그 내엔 데이터를 JS 코드로 인식하기에 Callback 함수를 활용해야합니다.

 

Cross Origin에 요청 시 callback 파라미터에 어떤 함수로 받아오는 데이터를 핸들링할지 넘겨주면,
대상 서버는 전달된 Callback으로 데이터를 감싸 응답합니다.

웹 리소스 요청 코드

<script>

/* myCallback이라는 콜백 함수를 지정합니다. */
function myCallback(data){

	/* 전달받은 인자에서 id를 콘솔에 출력합니다.*/
    console.log(data.id)

}

</script>

<!--
https://theori.io의 스크립트를 로드하는 HTML 코드입니다.
단, callback이라는 이름의 파라미터를 myCallback으로 지정함으로써
수신측에게 myCallback 함수를 사용해 수신받겠다고 알립니다.
-->
<script src='http://theori.io/whoami?callback=myCallback'></script>

웹 리소스 요청에 따른 응답 코드

/*
수신측은 myCallback 이라는 함수를 통해 요청측에 데이터를 전달합니다.
전달할 데이터는 현재 theori.io에서 클라이언트가 사용 중인 계정 정보인
{'id': 'dreamhack'} 입니다. 
*/

myCallback({'id':'dreamhack'});

위에 예시 코드는 <script src=.. 부분에 Cross Origin의 데이터를 불러옵니다.
이때 callback 파라미터로 myCallback을 함께 전달하죠

 

Cross Origin에 응답할 데이터를 myCallback 함수의 인자로 전달될 수 있도록 myCallback으로 감싸
JavaScript 코드로 반환, 반환 코드는 요청측에 실행되기에 3-6번 줄에 정의된 함수가 전달된 데이터 읽음

 

다만 JSONP는 CORS가 생기기전에 사용된 거라 요즘은 사용 안해요 ㅎ

---

핵심 키워드

 

• Same Origin Policy (SOP): 동일 출처 정책
  - 현재 페이지의 출처가 아닌 다른 출처로부터 온 데이터를 읽지 못하게 하는 브라우저의 보안 메커니즘
• Same Origin: 현재 페이지와 동일한 출처
• Cross Origin: 현재 페이지와 다른 출처
• Cross Origin Resource Sharing (CORS): 교차 출처 리소스 공유
  - SOP의 제한을 받지 않고 Cross Origin의 데이터를 처리 할 수 있도록 해주는 메커니즘

---

참고 자료

Mitigation: Same Origin Policy

 

참고 이미지