Web Hacking : Mitigation SOP / CORS

Minchae Kim·2023년 8월 6일

Web Hacking

목록 보기

4/8

📌 Same Origin Policy

이용자가 악의적인 페이지를 접속했을 때, 페이지가 자바스크립트를 사용해 이용자의 SNS 웹 서비스로 요청을 보낸 경우를 가정해보자. 브라우저는 요청을 보낼 때 헤더에 해당 웹 서비스 쿠키를 포함시킬 것이다. 따라서 자바스크립트로 요청을 보낸 페이지는 로그인 된 이용자의 SNS 응답을 받을 것이다. 더불어 마음대로 페이지 접속자의 SNS에 글을 올리거나, 삭제하고, SNS 메신저를 읽는 것도 가능할 것이다.

이와 같은 문제를 방지하기 위해 동일 출처 정책, Sam Origin Policy (SOP) 보안 메커니즘이 탄생했다. SOP는 클라이언트 사이드 웹 보안에 있어 중요한 요소이다. 실제로 클라이언트 사이드 공격은 이 SOP를 우회하기 위한 것이다.

🚩 SOP란?

이용자가 웹 서비스에 접속할 때, 브라우저는 해당 웹 서비스에서 사용하는 인증 정보인 쿠키를 HTTP 요청에 포함시켜 전달한다. 직접 접속하는 것 외에도, 브라우저는 웹 리소스를 통해 간접적으로 타 사이트에 접근할 때도 인증 정보인 쿠키를 함께 전송하는 특징을 갖고 있다.

이러한 특징 때문에 악의적인 페이지가 클라이언트의 권한을 이용해 대상 사이트에 HTTP 요청을 보내고, HTTP 응답 정보를 획득하는 코드를 실행할 수 있다. 클라이언트 입장에서는 가져온 데이터를 악의적인 페이지에서 읽을 수 없도록 해야 하며, 이것이 바로 브라우저의 보안 메커니즘인 동일 출처 정책 (Sam Origin Policy, SOP)이다.

🔹 Origin 구분 방법

브라우저가 가져온 정보의 출처인 오리진(Origin)을 구분해야 한다. 오리진은 프로토콜 (Protocol, Scheme), 포트 (Port), 호스트 (Host) 로 구성된다. 구성 요소가 모두 일치해야 동일한 오리진이라고 한다.

https://same-origin.com/frame.html라는 오리진과 아래 URL을 비교해보자.

https://same-origin.com/frame.html : Same Origin / Path만 다름
http://same-origin.com/frame.html: Cross Origin / Scheme이 다름
https://cross.same-origin.com/frame.html : Cross Origin / Host가 다름
https://same-origin.com:1234/ : Cross Origin / Port가 다름

🚩 SOP 실습

SOP는 Cross Origin이 아닌 Same Origin일 때만 정보를 읽을 수 있도록 해준다. 아래의 코드에 적힌 window.open은 새로운 창을 띄우는 함수이며, object.location.href는 객체가 가리키고 있는 URL 주소를 읽어오는 코드이다.

🔹 Same Origin

sameNewWindow = window.open('https://dreamhack.io/lecture');
console.log(sameNewWindow.location.href);
> // 결과 : https://dreamhack.io/lecture

🔹 Cross Origin

crossNewWindow = window.open('https://theori.io');
console.log(crossNewWindow.location.href);
> // 결과 : Origin 오류 발생

위와 같이 외부 출처에서 불러온 데이터를 읽으려고 할 때는 오류가 발생해 읽지 못한다. 하지만 읽는 것 외에 데이터를 쓰는 것은 문제 없이 동작한다.

🚩 SOP 데모

아래의 코드는 모듈 구성 코드로 간단한 실습 이전에 코드를 이해하고 넘어가면 된다.

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

<!-- 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>

🔹 Same Origin 버튼

앞선 과정이 모두 성공적으로 수행되어 treasure라는 값이 출력된다.

Console : {"secretValue":"treasure"}

🔹 Cross Origin

앞선 과정 중, 세 번째 과정이 실패하여 Cross Origin의 데이터에 접근할 수 없다는 오류가 출력된다.

Console : {"error":{"stack":"Error: Blocked a frame with origin "https://same-origin.com/" from accessing a cross-origin frame.
at HTMLIFrameElement.myFrame.onload (https://same-origin.com/:6:51)"}}

🚩 Same Origin Policy 제한 완화

SOP는 클라이언트 사이드 웹 보안에서 중요한 소요이긴 하나, 브라우저가 이러한 SOP에 구애 받지 않고 외부 출처에 대한 접근을 허용해주는 경우가 존재한다. 예를 들면, 이미지나 자바스크립트, CSS 등의 리소스를 불러오는 <img>, <style>, <script> 등의 태그는 SOP의 영향을 받지 않는다.

위 경우들 외에도 웹 서비스에서 동일 출처 정책인 SOP를 완화하여 다른 출처의 데이터를 처리해야 하는 경우도 있다. 예를 들어 특정 포털 사이트가 카페, 블로그, 메일 서비스를 아래의 주소로 운영하고 있다고 하자. 각 서비스의 Host가 다르기 때문에 브라우저는 각 사이트의 오리진이 다르다고 인식한다.

이러한 환경에서, 이용자가 수신한 메일의 개수를 메인 페이지에서 출력하려면, 개발자는 메인 페이지에서 메일 서비스에 관련된 리소스를 요청하도록 해야 한다. 이때 두 사이트는 오리진이 다르므로 SOP를 적용받지 않고 리소스를 공유할 방법이 필요한데, 이러한 공유 방법을 교차 출처 리소스 공유 (Cross Origin Resource Sharing, CORS)라고 한다.

교차 출처의 자원을 공유하는 방법은 CORS와 관련된 HTTP 헤더를 추가하여 전송하는 방법을 사용한다. 이 외에도 JSON with Padding (JSONP) 방법을 통해 CORS를 대체할 수 있다.

CORS란 앞서 설명했듯이, HTTP 헤더에 기반하여 Cross Origin 간에 리소스를 공유하는 방법이다. 발신측에서 CORS 헤더를 설정해 요청하면, 수신측에서 헤더를 구분해 정해진 규칙에 맞게 데이터를 가져갈 수 있도록 설정한다.

🔹 웹 리소스 요청 코드

웹 리소스를 요청하는 발신 측 코드의 일부이다.

/*
    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 요청

아래의 코드를 살펴보면, Access-Control-Request로 시작하는 헤더가 존재하는 것을 확인할 수 있다. 해당하는 헤더 뒤에 따라오는 Method와 Headers는 각각 메소드와 헤더를 추가적으로 사용할 수 있는지 질의한다.

동시에 해석해보면, 웹 리소스 요청 코드에서 POST 방식으로 HTTP 요청을 보냈으나 OPTION 메소드를 가진 HTTP 요청이 전달된 것을 확인할 수 있다. 이를 CORS preflight라고 하며, 수신 측에 웹 리소스를 요청해도 되는지 질의하는 과정이다.

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/

🔹 서버의 응답

위처럼 질의하면 서버는 아래와 같이 응답한다.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://dreamhack.io
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type

아래는 응답 결과에 대한 설명이다.

Access-Control-Allow-Origin : 헤더 값에 해당하는 Origin에서 들어오는 요청만 처리한다.
Access-Control-Allow-Methods : 헤더 값에 해당하는 메소드의 요청만 처리한다.
Access-Control-Allow-Credentials : 쿠키 사용 여부를 판단합니다. 예시의 경우 쿠키의 사용을 허용한다.
Access-Control-Allow-Headers : 헤더 값에 해당하는 헤더의 사용 가능 여부를 나타낸다.

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

🚩 JSON with Padding (JSONP)

앞서 설명했듯이, 이미지나 자바스크립트, CSS 등의 리소스는 SOP에 구애 받지 않고 외부 출처에 대한 접근을 허용한다. JSONP 방식은 이러한 특징을 이용해 <script> 태그로 Cross Origin의 데이터를 불러온다.

그러나 <script> 태그 내에서는 데이터를 자바스크립의 코드로 인식하기 때문에 Callback 함수를 활용해야 한다. Cross Origin에 요청할 때 callback 파라미터에 어떤 함수로 받아오는 데이터를 핸들링할지 넘겨주면, 대상 서버는 전달된 Callback으로 데이터를 감싸 응답한다.

아래의 코드를 살펴보면, 맨 마지막 줄에서 Cross Origin의 데이터를 불러온다. 이때 callback 파라미터로 myCallback을 함께 전달한다. Cross Origin에서는 응답할 데이터를 myCallback 함수의 인자로 전달될 수 있도록 myCallback으로 감싸 자바스크립트 코드를 반환해준다. 반환된 코드는 요청 측에서 실행되기 때문에 정의된 myCallback 함수가 전달된 데이터를 읽을 수 있다.

<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'});

다만 JSONP는 CORS가 생기기 전에 사용하던 방법으로 현재는 거의 사용하지 않는 추세이기 때문에, 새롭게 코드를 작성할 때에는 CORS를 사용해야 한다.

Minchae Kim

The Bloom of Youth

이전 포스트

Web Hacking : Cookie & Session

다음 포스트

Web Hacking : Mitigation SOP / CORS

Web Hacking

📌 Same Origin Policy

🚩 SOP란?

🔹 Origin 구분 방법

🚩 SOP 실습

🔹 Same Origin

🔹 Cross Origin

🚩 SOP 데모

🔹 Same Origin 버튼

🔹 Cross Origin

🚩 Same Origin Policy 제한 완화

🔹 웹 리소스 요청 코드

🔹 발신 측의 HTTP 요청

🔹 서버의 응답

🚩 JSON with Padding (JSONP)

Web Hacking : Cookie & Session

Web Hacking : ClientSide - XSS

0개의 댓글

Web Hacking : Mitigation SOP / CORS

Web Hacking

📌 Same Origin Policy

🚩 SOP란?

🔹 Origin 구분 방법

🚩 SOP 실습

🔹 Same Origin

🔹 Cross Origin

🚩 SOP 데모

🔹 Same Origin 버튼

🔹 Cross Origin

📌 Cross Origin Resource Sharing (CORS)

🚩 Same Origin Policy 제한 완화

🚩 Cross Origin Resource Sharing (CORS)란?

🔹 웹 리소스 요청 코드

🔹 발신 측의 HTTP 요청

🔹 서버의 응답

🚩 JSON with Padding (JSONP)

Web Hacking : Cookie & Session

Web Hacking : ClientSide - XSS

0개의 댓글