1-1. CORS 개념과 Origin에 대해

 

작성배경

CORS는 그냥 다른 사이트에서 접근하는 것을 막아주는 거라고 했다..! 정도의 지식을 갖고 있어

스스로 부끄러움이 느껴져 해당 글을 작성하면서 공부해본다.

예전에 신입 면접보려고... 접근 허용된 url~? 오브CORS~ 하고 외우기만 했던 기억이..ㅎ

오늘 Request 헤더에 Origin이 있고 CORS 관련 응답 헤더가 있는 패킷을 본 적이 있어서,

잘만 하면 뭔가뭔가의 취약점이 있을 것 같은데 잘 되지 않기도 했다.

이번에는 bugbounty club이라는 곳을 통해서

CORS 개념, 동작원리, 취약한 환경에서 실습도 하며 공부해보려고 한다.

아래 그림을 보면 모니터 속의 외부 공격자는 CONFIDENTIAL이라고 적힌 기밀 문서를 읽는 그림인데 인상 깊다.

https://www.bugbountyclub.com/pentestgym/view/60

 

 

CORS?

CORS는 Cross-site Origin Sharing의 약자로 '교차 출처 리소스 공유'라고 한다.

위에서 '다른 곳에서의 접근을 막아주는...'이라고 알고 있었다고 했는데,

그 '다른 곳'의 개념이 Cross-site Origin인 것이다.

다른 곳은 무엇이고 무슨 접근을 어떻게 막는다는 걸까?

아직까진 감이 잘 안 잡힌다고 치자.

 

'다른 곳', Cross-site Origin이란?

Origin은 영어로는 출처, 쉽게 말하면 여기에서는 요청자의 URL이다.

어떤 url에서 서버의 Response를 원하는가?를 말한다.

URL의 기본적인 구조는 아래 포스팅에 잘 소개되어 있어 강력 추천한다. (읽는 데 1분도 안 걸림ㅎ)

https://www.grabbing.me/URL-018cdd1bb4b541fab6246569244fcf93

URL 중 1) 프로토콜, 2) 도메인 네임, 3) 포트번호가 모두 일치하면 Cross-site가 아닌 Same-site 취급한다.

즉 이 셋 중 하나라도 다르면 '다른 곳' 취급을 받는다는 것이다.

https://www.example.com에서 https://api.example.com을 통해 어떤 데이터를 가져오고 싶다고 하면,

이 요청은 도메인이 다르기에 Cross-Origin Request가 된다.

 

 

그렇다면 '같은 곳'인 Same-site Origin은?

위에서 설명한 프로토콜/도메인 네임/포트번호가 모두 일치하는 URL에서의 요청을 뜻한다.

이 Same-site Origin에서만 접근을 허용하기 위한 SOP(Same Origin Policy, 동일 출처 정책)는

Same Origin이 아닌 경우 서버로의 데이터 사용을 차단하는 보안 메커니즘이다.

웹 브라우저에서 차단 또는 허용이 이루어지는데, SOP와 CORS를 잘 알지 못하면 혼동하는 것 중 가장 큰 부분이다.

 

아래 그림처럼 Same Origin인 service.example.com 간의 통신은 가능하고,

Cross Origin인 api.example.com과는 통신이 차단되는 것이 SOP라고 볼 수 있다.

https://core-research-team.github.io/2021-04-01/Easy-to-understand-Web-security-model-story-1%28SOP,-CORS%29

 

 

 

CORS, 구하러 왔구나 형!

CORS 사용 이유

한 줄로 정리하자면 'SOP의 제약성에 대한 완화, 또는 예외 정책'이라고 할 수 있겠다.

SOP는 CSRF를 방어하기 위한 하나의 방법으로 사용되곤 했지만,

근본적으로 CSRF 방어만을 수행하는 CSRF 토큰 방식과 달리

SOP를 적용받는 XMLHttpRequest(Ajax와 같은 비동기 데이터 교환)나 Fetch API를 통해

원하는 데이터를 얻는 것조차 막아버리니 문제가 되었다.

CORS는 SOP와 대적(?)해서, '내가 설정해 둔 URL에 한해서는 접근을 허용하겠다!'라고 명시하는 것이다.

CORS를 사용함으로써 특정 형태의 Request를 통해(위에 작성한 많이들 사용하시는 Ajax, 기타 API)

다른 서버로부터 데이터를 받아와 가공 및 처리가 가능해진다.

 

 

그냥 SOP를 없애고 CORS만 쓰면 안되나요?

그건 또 곤란하다고 한다. SOP를 사용함으로써 아래 그림과 같은 상황을 방지할 수 있다.

(case) 사용자 의지와 무관하게 악성 사이트에 접속 > 악성 스크립트 실행 > 임의 사이트에 요청 > 응답 값이 악성 사이트로 전송 > 개인정보 탈취..etc....omg,,wtf...

뭐 물론 방대한 시나리오긴 하지만, 요즘 공격들 수준보면 영 불가한 것도 아니다. 

https://core-research-team.github.io/2021-04-01/Easy-to-understand-Web-security-model-story-1%28SOP,-CORS%29

 

위와 같은 case 외에도 1) 사용자가 접속하고 있는 내부망 ip 및 포트 스캐닝, 

2) 요청하게 되는 사이트 <-> 악성 사이트 간 사용자 브라우저가 프록시화 될 수도 있다.

굳이 'SOP가 없기 때문!'이라고 말하기엔 부족하지만,

XSS/CSRF를 비롯해 다양한 악성 행위의 근원이 될 수도 있다고 본다.

 

 

정리

내가 접속한, 접속하려는 사이트들을 신뢰하지 않는 웹 브라우저의 'SOP'와

데이터 교환에 엄격한 제약을 받고 싶지 않을 때 보안성을 지키며 사용 가능한 'CORS'.

둘 모두 헤더를 통해 웹 브라우저에서 검증을 수행한다는 것을 혼동해서는 안 되겠다.

높은 수준의 보안을 유지하면서 외부로부터의 공격을 방지하려면

준수해야 할, 또는 기업의 비즈니스 로직을 위한 맞춤형 CORS 설정도 만만치 않을 것 같다.

다음 글들은 CORS를 설정하기 위한 Request, Response 단의 다양한 소스코드들을 알아본다.