1. 공부배경
- Spring 프로젝트에 CORS를 적용하려고 공부하려 여러 블로그글을 정리하던 중 글마다 조금 헷갈리게 표현된 것들이 있어 핵심만 모아 정리해보았다.
2. 공부내용
- 구글링을 통해 나온 많은 글이 SOP가 XSS나 CSRF를 방지하기 위해 도입됐다 혹은 막아줄 수 있다고 설명한다. 그런데 SOP와 이를 해결하기 위한 CORS기술을 공부할 수록 이 기술은 XSS를 막을 수 없다는 생각이 들었다. 아래는 cloud flare에서 가져온 XSS 모식도이다. 일반적인 XSS 공격은 스크립트로 하여금 사용자 정보를 공격자에게 전송하거나 악의적인 행위를 하게끔 유도하는 방식이다.
-
CORS는 응답서버 측에서 해당 요청이 정상적인 요청인지를 확인해주는 역할을 한다.
- 그림을 순서대로 보면
- 사용자는 Server A로 요청을 보낸다.
- Server A는 사용자 요청에 따라 웹 페이지를 전송한다
- Server A의 웹페이지 내에는 Server B로부터 리소스를 받기 위한 script가 포함되어 있다.
- 사용자는 origin헤더에 A를 명시하고 Server B로 리소스를 요청한다.
- Server B는 Access-Control-Allow-Origin에 허용하는 origin목록을 클라이언트에 보낸다.(시나리오 설명을 위해 preflight는 제외한다고 가정했다)
- 사용자는 origin과 Server B의 Access-Control-Allow-Origin 헤더를 비교해서 값이 다를 경우 리소스를 로드하지 않는다.
- 그림을 순서대로 보면
-
내가 SOP가 XSS를 막을 수 없다고 생각한 이유는 Access-Control-Allow-Origin의 발행주체가 서버이기 때문이다. 정보를 수집하는 Attacker의 서버가 Access-Control-Allow-Origin : * 설정을 해버리면 사용자 브라우저는 CORS 에러를 발생시키지 않는다.
-
일반적으로 XSS는 정상 사이트 내에 공격자가 악의적인 스크립트를 삽입하는데, 정상 사이트로부터 스크립트를 로드하는 것은 SOP와는 관련이 없다. 그렇기 때문에 웹페이지 내에 삽입된 악성코드는 브라우저에 로드되고 악의적인 행위를 수행할 수 있다.
-
SOP가 공격을 막아줄 수 있는 시나리오는 아래와 같다.
- 그림을 순서대로 보면
- 사용자가 실수로 hacker 사이트에 접속한다.
- hacker는 악의적인 스크립트가 포함된 웹페이지를 전송한다.
- 스크립트는 사용자가 특정 사이트를 접속해서 리소스를 요청하도록 작동한다.
- 사용자는 origin헤더에 attacker를 명시하고 정상서버로 리소스를 요청한다.
- 정상서버는 attacker가 정상적인 origin이 아니기에 응답 자체를 거부할 수도 있고, Access-Control-Allow-Origin 리스트에 정상서버 리스트만 담아 보낼 수도 있다.
- 사용자는 origin과 Server B의 Access-Control-Allow-Origin 헤더를 비교해서 값이 다르기 때문에 추가적인 리소스를 로드하지 않는다.
- 그림을 순서대로 보면
- 위 시나리오를 보면 SOP는 XSS 보단 오히려 CSRF에 가까운 시나리오를 막는 데 유용해 보인다.
* 다만 ChatGPT에서는 SOP는 XSS를 막기위한 용도이지 CSRF와는 관련이 적다고 이야기한다.
3. 정리
- SOP는 서로 다른 origin의 리소스 로드를 브라우저가 막는 기술이다.
- SOP로 인한 제한사항을 해결하는 기술이 CORS인데 CORS 관련 헤더는 서버가 담당한다.
- 서버가 공격자에 의해 조작 가능한 경우에는 SOP를 이용한 방어가 불가능하다.(Access-Controll-Allow-Origin 헤더를 조작해 브라우저가 리소스를 로드하도록 유도 가능)
- 일반적으로 XSS로 유도되는 request가 공격자 서버로의 정보유출, 추가적인 스크립트 로드인 점을 고려하면, SOP가 XSS를 막기 위한 기술이라고 설명하는 건 부적절
ㆍ