[빡공팟 5기] W4 : Web Hacking 로드맵 - STAGE 2 - 1

Mitigation : Same Origin Policy

 

쿠키에는 인증 상태를 나타내는 민감한 정보가 보관되며, 브라우저 내부에 저장된다.

브라우저가 웹 서비스에 접속할 때 브라우저는 자동으로 쿠키를 헤더에 포함시켜 요청한다.

이용자가 악의적인 페이지에 접속했을 때,

페이지가 자바스크립트를 사용해 이용자의 SNS 웹 서비스로 요청을 보낸다면 로그인 된 이용자의 SNS 응답을 받을 것이다.

그렇게 된다면 마음대로 페이지 접속자의 SNS 에 글을 쓰고, 삭제하고, 읽는 것이 가능해진다.

이와 같은 문제를 방지하기 위해서 Same Origin Policy(SOP), 동일 출처 정책 보안 메커니즘이 탄생했다.

 

1. Same Origin Policy(SOP) 란?

클라이언트 사이드 웹 보안에 있어 중요한 요소이다.

실제로 클라이언트 사이드 공격은 이러한 SOP 를 우회하기 위한 것이라고 생각하면 된다.

이용자가 웹 서비스 접속 시, 해당 웹 서비스에서 사용하는 인증 정보인 쿠키를 HTTP 요청에 포함시켜 전달한다.

사이트 직접 접속하는 것에만 한정되지 않고, 브라우저는 웹 리소스를 통해 간접적으로 타 사이트에 접속할 때도

인증 정보인 쿠키를 함께 전송한다.

이 특징으로 인해 악의적인 페이지가 클라이언트의 권한을 이용해 대상 사이트에 HTTP 요청을 보내고,

응답 정보를 획득 하는 코드를 실행할 수 있다.

따라서, 클라이언트 입장에서는 가져온 데이터를 악의적인 페이지에서 읽을 수 없도록 해야하고 이것이 바로 SOP 이다.

 

브라우저가 가져온 정보의 출처인 오리진(Origin)을 어떻게 구분할까?
오리진은 URL 의 Scheme, Port, Host 로 구성된다. 이 3가지의 구성 요소가 모두 일치해야 동일한 오리진이라고 한다.
SOP 는 Cross Origin 이 아닌 Same Origin 일 때만 정보를 읽을 수 있도록 한다.

 

2. Cross Origin Resource Sharing (CORS)

SOP에 구애 받지 않고 외부 출처에 대한 접근을 허용해주는 경우가 존재한다.

예시를 들면, 이미지, 자바스크립트, CSS 등의 리소스를 불러오는 <script></script> 등의 태그는 SOP 의 영향을 받지 않는다.

교차 출처 리소스 공유는 HTTP 헤더에 기반하여 Cross Origin 간에 리소스를 공유하는 방법이다.

발신측에서 CORS 헤더를 설정하여 요청하면 수신측에서 헤더를 구분하여 정해진 규칙에 맞게 데이터를 가져갈 수 있도록 설정한다.

발신측에서 POST 방식으로 HTTP 요청을 보냈으나 OPTIONS 메소드를 가진 HTTP 요청이 전달되었다.

이를 CORS preflight 라고 하며, 수신측에 웹 리소스를 요청해도 되는지 질의하는 과정이다.

 

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

 

위 과정을 마친뒤에 브라우저는 수신측의 응답과 발신측의 요청을 확인하고, 그때 POST 요청을 보내서 수신측의 웹 리소스를 요청하는 HTTP 요청을 보낸다.

 

3. JSON With Padding (JSONP)

JSONP 는 이미지나 자바스크립트, CSS 등의 리소스는 SOP 에 구애 받지 않는 특징을 이용하여

<script> 태그로 Cross Orgin 의 데이터를 불러온다.

태그 내에서 Callback 함수를 활용해야한다.

그러나 이 방법은 CORS 가 생기기전에 사용하던 방법이므로 요즘은 거의 사용하지 않는다.

 

---

처음 접해본 개념이라 생소하고 이해가 잘 되지 않는다.

따라서 실습 코드를 직접 작성하면서 더 공부하고 내용을 추가해야 할 것 같다!