다른 출처에서 리소스를 읽는 것을 사전에 차단하지 않으면 발생할 수 있는 문제

 

교차 출처 리소스 공유(CORS)를 이번에는 알고 넘어가야 할 것 같아서 잠깐의 시간을 들여 자료를 찾아보고 있었다. MDN Web Docs에서 정의하고 있는 CORS의 정의는 다음과 같다.

 

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다.
... 보안 상의 이유로, 브라우저는 스크립트에서 시작한 교차 출처 HTTP 요청을 제한합니다.

 

 

다른 웹 사이트들에서 확인할 수 있었던 정의도 대부분 비슷했다. 요지는 Protocol, Host(도메인), Port가 같아야만 서버로부터 데이터를 받을 수 있는 동일 출처 정책(Same-Origin Policy, SOP)을 따르는 것이 기본이고, 교차 출처 리소스 공유를 허용받기 위해서는 Simple Request와 Preflight Request 방식을 이용해 요청을 보내기 전 사전에 추가 요청을 이행해야 한다는 점이었다.

 

정보들은 다른 글들에서 찾아볼 수 있으므로 넘어가고, 왜 막아야 하는 것인지 궁금했다.

 

관련해서 찾은 글들 중 교차 출처 리소스 공유를 막지 않을 경우 생길 수 있는 문제점의 사례를 제시하는 글이 있었다.

 

 

이러한 SOP의 빡빡한 정책 때문에 외부에서 데이터를 불러오진 못하지만, CSRF나 XSS 같은 보안 취약점 공격으로부터 안전하다는 장점이 있습니다.

 

[WEB] 동일 출처 정책(SOP)과 교차 출처 리소스 공유(CORS)란?

 

 

해당 글에서 언급한 'CSRF나 XSS 같은 보안 취약점 공격'이 어떤 내용인지 궁금해 찾아보았다.

 

Cross Site Scripting (XSS)

XSS는 서버에 script 태그가 포함된 비정상적인 데이터를 서버에 전달하여 웹 페이지에 악성 스크립트를 삽입하는 방식의 공격이다. 간단한 예로 사용자가 input 영역을 작성할 때 악성코드를 삽입하는 방식이 있다. 만약 웹 페이지에 악성코드가 삽입된 뒤, 다른 클라이언트로부터 요청을 받아 서버가 응답할 경우, 클라이언트는 해당 악성코드가 포함된 응답을 믿을 수 있는 웹 서버에서 들어오는 것으로 간주하여 악성코드를 실행하게 할 수 있다.

 

XSS와 CORS 간의 상관관계를 명확히 찾기는 쉽지 않았다. 다음 블로그의 글을 시간이 날 때 추가적으로 읽어 볼 필요가 있을 것 같다.

XSS 대응방안

 

 

Cross Site Request Forgery (CSRF)

CSRF는 특정 사이트에 인증된 사용자 정보를 이용해 해커가 원하는 작업을 강제로 수행하게 하는 공격이다. 공격 과정은 다음의 방법으로 이루어진다.

1. 희생자가 위조 요청을 보낼 사이트에 로그인되어 있는 상태에서 해커가 만든 피싱 사이트에 접속한다.
2. 희생자가 피싱 사이트에 접속하면 피싱 사이트에서 희생자로 가장해 요청을 위조해 전송한다.
3. 위조 요청을 받은 사이트는 해당 요청에 대해서 응답을 하고, 이로 인해 희생자가 의도하지 않은 행동이 실행된다.

CSRF를 방지할 수 있는 방법 중 하나로는 Referrer 검증이 있다. Request Header에 있는 요청을 특정 페이지의 정보가 담긴 Referrer 속성을 검증해 차단하는데, 같은 도메인 상에서 요청이 들어오지 않는다면 차단하는 방법이다.

csrf & cors