Cross-Origin Resource Sharing

동일 출처 정책 (SOP)

• 브라우저에서 서버에 요청을 보낼 때, 출처가 같지 않으면 차단하는 정책
  • 2011년 RFC 6454에서 등장
• 브라우저에서 서버에 요청을 보낼 때는, 클라이언트의 Origin과 서버의 Origin이 같아야 동일 출처 정책에 의해 차단되지 않음.
• 이는 백엔드에서 요청을 보낼 때에는 적용되지 않고, 브라우저에서 요청을 보낼 때만 적용된다. 출처 비교와 차단은 브라우저에 구현된 스펙이다. (서버에 구현된 스펙이 아니다)
• 브라우저는 사용자의 개인정보를 담고있고, 이러한 제약이 없다면 해커가 CSRF(Cross-site request forgery)나 XSS(Cross-site scripting)등의 방법을 이용하여 개인정보를 가로챌 수 있기 때문이다.
  • 기존 사이트와 완전히 동일하게 동작하도록 꾸며놓고, 사용자의 로그인을 유도하여 악의적으로 정보를 탈취할 수 있음

[참고] 출처(Origin)

• 우리가 어떤 사이트에 접속할 때 사용하는 URL은 다음과 같은 구성요소로 이루어져 있다.

• 여기서 Origin은 Protocol + Host + Port 이다.
• 따라서 Cross-Origin 이란 다음과 같은 경우를 말한다.
  1. Protocol: HTTP에서 HTTPS로 요청할 경우
  2. Host: domain.com 에서 other-domain.com 으로 요청할 경우
     • domain.com 에서 www.domain.com 으로 요청한다면 Cross-Origin 일까?
     • https://datatracker.ietf.org/doc/html/rfc6454#section-3.2.1
     • https://docs.tosspayments.com/resources/glossary/cors
  3. Port: 3000에서 8080으로 요청할 경우
     • PORT 번호가 생략되어 있다면? RFC 2616
       • HTTP: 80 / HTTPS: 443
       • 브라우저에 따라 다른 출처 비교 로직 존재 (IE의 경우 출처 비교 시 포트 번호를 완전 무시…)

[참고] XSS (Cross-Site Scripting)

XSS 공격을 직접 해보면서 알아보기(dangerouslySetInnerHTML는 얼마나 위험할까?)

[참고] CSRF (Cross-Site Request Forgery)

• 사이트 간 요청 위조 → 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(데이터 수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격
  1. 사용자가 사이트에 로그인
  2. API 요청 헤더가 사용자의 브라우저 쿠키에 저장
  3. 공격자가 사용자로 하여금 악성 스크립트 페이지를 누르도록 유도
     • 게시판이 있는 웹사이트에 악성 스크립트를 게시글로 작성하여 유도
     • 메일 등으로 악성 스크립트를 직접 전달
  4. 악성 스크립트 페이지 접근 시 웹 브라우저에 의해 쿠키에 저장된 헤더와 함께 서버에 요청
     • SOP가 해당 요청을 방지할 수 있음
  5. 서버는 해당 요청을 처리
• 사례: 2008년 옥션 개인정보 유출 사건 (피해 회원 총 1863명)
  • 사건 경위

CORS

• CORS(Cross-Origin Resource Sharing)는 다른 출처의 리소스 공유에 대한 허용/비허용 정책
• SOP라는 원칙에 대한 예외
• CORS 정책을 따르면 다른 출처의 리소스라도 서버와 브라우저 간에 주고받을 수 있게 된다.