SOP & CORS 가 뭘까?

 

 

SOP & CORS 에 대하여 알아보겠습니다!

 

     <목차>

1. Origin 이란?

2. SOP

3. CORS

 

---

<Origin 이란?>

 

SOP 와 CORS 정책에 알아보기 전에 Origin 이라는 개념에 대하여 알아볼 필요가 있습니다.

 

Origin 은 '출처' 를 의미하며 , 구성은 프로토콜(스키마) , 호스트명 , 포트 로 이루어져 있습니다.

 

 

https://www.vulnum.com:1458

     ↓                   ↓                    ↓     

프로토콜-------호스트명----------포트-

 

이런식의 구성이 바로 Origin 이며 기본적으로 포트는 경로 앞에 :443이 붙어있습니다.

(포트는 작성을 안할시 자동적으로 443포트가 할당된다. 지금은 1458이 할당되어 있습니다.)

※ http 는 기본포트가 80 ,https 는 기본포트가 443.

 

---

 

※ Referer 이랑 헷갈릴 수 있는데 Referer 은 경로랑 쿼리까지 전부 포함합니다. (전체 URL을 포함)

 

https://www.vulnum.com/mainpage?username=mooner&page=1#foo

     ↓                   ↓                       ↓                                ↓                            ↓

프로토콜-------호스트명---------------경로------------------------쿼리---------------------프래그먼트-

 

 

---

<SOP(Same-Origin Policy)>

" 같은 출처(Origin)에서만 리소스를 공유할 수 있습니다"

 

-개발을 하다보면 다른 도메인의 정보가 필요할때가 있는데 , SOP 정책으로 인하여 도메인이 서로 다른 주소끼리 정보를 

가져올 수 없게됩니다.

 

좀 더 풀어서 이야기해드리자면 ,제가 'www.mooner.com/wirte' 페이지에서 <iframe src="www.naver.com">  이란 태그를를 작성하여 'naver.com' 창을 띄울순 있지만(응답을 받을순 있다.) , naver 페이지에서 자바스크립트로 DOM 파일에 접근하여 'naver.com' 에 있는 내용을 가져올 올 순 없다는 뜻입니다.

<iframe> 으로 로드된 페이지에 자바스크립트로 접근이 불가능하다는거지 , <iframe> 태그가 로드가 안되는건 아님!

 

요약하자면 다른출처를 대상으로 자바스크립트를 사용할 수 없다는 뜻입니다.

 

그러면 이런 의문이 듭니다.

"출처가 다르다는 기준이 뭔데?"

 

< http://store.company.com/dir/page.html URL 과 비교한 출처비교>

URL	결과	이유
http://store.company.com/dir2/other.html	동일 출처	경로만 다름
http://store.company.com/dir/inner/another.html	동일 출처	경로만 다름
https://store.company.com/page.html	실패	다른 프로토콜
http://store.company.com:81/dir/page.html	실패	다른 포트
http://news.company.com/dir/page.html	실패	다른 호스트

 

---

 

또 하나 재밌는것이 자바스크립트를 사용하려 할때 막는주체는 서버가 아닌 클라이언트의 브라우저 입니다.

 

브라우저 자체에서 정책으로 막아놓은 것 입니다.

 

그런데 이 빡빡한 SOP정책 때문에 도저히 개발을 하면서 뭘 할수가 없는겁니다.

 

자고로 개발을 하려면 이것저것 가져와야 할텐데 말이죠....확장성이 없어진 것입니다.

 

 

그래서 나온것이 CSRF 입니다.  

---

<CSRF(Cross Origin Resource Sharing)>

:"몇가지 규칙을 줄게! 만약 해당되면 자바스크립트로 다른출처의 데이터를 사용할 수 있어!"

 

개발자: "좋아 , 그러면 그 규칙이 뭔데?"

 

브라우저 : "응답에 있는 ACAO 헤더 (Access-Controll-Allow-Origin)을 보고 판단을 할게!"

 

ACAO 헤더?

- ACAO 응답 헤더 (Access-Controll-Allow-Origin) 는 이 응답이 주어진 Origin 과 데이터를 공유할 수 있는지를 나타냅니다. ex) ACAO: www.moooner.com 이라고 되어있으면 ACAO 응답을 준 페이지의 데이터를 자바스크립트 등으로 직접 접근이 가능해집니다.

 

---

 

하지만 이 ACAO 헤더에 등록을 하려면 개발자가 일일히 허락되는 주소를 기입해야 한다는 단점이 있습니다. 그래서 ACAO: * 라고 설정하는 편법을 사용하기 시작했습니다.

 

브라우저를 안쓸순 없고 개발을 하자니 CSRF 정책에 자꾸 걸리니깐 ,일일히 ACAO를 다 기입하기보단 그냥 모든 주소에서 허락되도록 쓰게 되었습니다.

 

하지만 이러면 SOP 를 시행한 의미도 없어지고 , 보안상으로 매우 위험해집니다.

 

그리하여 브라우저는 조건을 또 추가하게 됩니다.

 

"알았어... ACAO:* 쓰는거 허락해줄게! 대신에 쿠키가 들어간 요청에서는 ACAO: * 쓰는거 불가능! , 쿠키가 들어간 요청은 ACAC 응답헤더를 통해 판단을 하게 될거야!"

 

ACAC 헤더 ?

ACAC(Access-Control-Allow-Origin) 헤더로 이 헤더의 값이 True 이면  *(와일드카드) 사용 불가!
이 헤더가 true 로 되어있으면 반드시 특정 도메인을 ACAO 에서 명시해줘야 한다!

 

 

---

 

※ 주의할 점

 

1. Origin 요청 헤더의 값 그대로 사용금지.

 

ACAO에서 *(와일드카드) 사용을 금지했다고 요청으로 온 Origin 헤더의 내용을 ACAO 헤더에 그대로 넣어버리는 경우가 있다. 이러면 *를 사용하지 않았지만 사실상 사용한 것과 같은 효과를 가지게 되는데 이건 보안상으로 매우 위험하다.

 

 

2.NULL 출처 허용 금지.

 

개발된 사이트를 배포하기전 로컬환경에서 테스트를 할때 Origin 이 null 로 설정이 되는데 , ACAO 헤더에 null 설정을 한 후 개발을 하다가 그대로 배포해버리는 경우가 있습니다.

 

이럴경우 ACAO:null 인 경우에도 허락이 된다는건데 보안상으로 매우 위험합니다.

 

가령 <iframe src="javascript:alert(1)"></iframe>  이라고 하면 Origin 이 null 인 요청이 보내질텐데 문제는 자바스크립트가 포함되어 있어서 공격자가 원하는 자바스크립트를 동작시키는게 가능해진다는 뜻입니다.

 

일반적으로 공격하려면 페이지 내부에서 XSS 취약점을 찾아야했는데 이렇게 되면 제가 만든 페이지로도 실제 서비스중인 사이트에 스크립트 공격이 가능해짐을 의미합니다.

 

 

 

참고문헌 : https://developer.mozilla.org/ko/docs/Web/Security/Same-origin_policy

---

 

 

긴 글 읽어주셔서 감사합니다!