안녕하세요. FE플랫폼팀 피터입니다 🙂 제가 소속된 FE플랫폼팀에서는 Chrome 업데이트 사항 중 사용자에게 영향을 미치는 기능을 리서치 후 사내 크루들에게 공유하고는 합니다.
이번에는 2021년 1월부터 업데이트되는 Chrome M88에 적용될 Schemeful same-site를 사내 크루들에게 공유하였는데요, Schemeful same-site는 같은 도메인의 HTTP 사이트와 HTTPS 사이트를 cross-site로 취급하도록 정책을 변경한 내용입니다.
관련해서 공식 문서를 통해 리서치한 내용을 공유 드리고자 합니다.
글의 순서는 다음과 같습니다.
- 용어정의
- 변경 사항과 목적이 무엇일까
- 확인이 필요한 부분
- 어떻게 대응할 수 있을까
- 요약
용어정의
본문에 작성된 용어의 혼란을 줄이기 위해 우선 용어를 설명해 드리겠습니다.
– scheme
URL에서 http, https 부분을 scheme라고 합니다. 예를 들어 https://daum.net에서 https 부분을 scheme라고 합니다.
– cross-scheme
같은 도메인인데 다른 scheme을 이동하는 관계를 cross-scheme라고 합니다. 예를 들어 도메인이 daum.net일 때, http://daum.net과 https://daum.net은 다른 scheme를 사용함으로 두 관계를 cross-scheme라고 합니다.
– 서브리소스
XHR 또는 Fetch로 만들어진 네트워크 요청과 iframe, image 등이 있습니다.
– form의 POST 메소드
<form method="POST"> 로 작성된 폼 양식을 submit하는 경우를 의미합니다.
변경 사항과 목적이 무엇일까
이전에는 같은 도메인의 HTTP 사이트와 HTTPS 사이트를 same-site로 취급했습니다. same-site로 취급하기 때문에 Cookie의 SameSite 속성을 Strict 또는 Lax로 설정하면 사이트 간의 Cookie를 보낼 수 있습니다.
하지만 Schemeful same-site가 적용된 후에는 HTTP 사이트와 HTTPS 사이트를 cross-site로 취급합니다. cross-site로 취급하기 때문에 Cookie의 SameSite 속성을 Strict로 설정하면 사이트 간의 Cookie를 보낼 수 없습니다. 때에 따라 Lax로 설정한 쿠키도 보낼 수 없으며 아래에서 자세히 설명하겠습니다.
Schemeful same-site의 주요 목적 중 하나는 HTTP 사이트에서 HTTPS 사이트에 Cookie를 요청할 때 발생할 수 있는 사이트 간 요청 위조(CSRF, Cross-Site Request Forgery) 공격의 취약점을 해결하고 사용자를 보호하기 위한 것입니다. Schemeful same-site의 영향으로 HTTP 사이트의 Cookie를 변조 후 HTTPS 사이트에서 사용할 수 없어서 이러한 사이트 간 요청 위조 공격에 대해서 무효화 할 수 있습니다.
확인이 필요한 부분
Schemeful same-site가 적용되면 세 가지 부분에서 확인이 필요합니다. 첫 번째는 cross-scheme 사이에 이동할 때, 두 번째는 iframe과 image와 같은 서브리소스 / form의 POST 메소드 요청, 세 번째는 WebSocket을 사용할 때입니다. 웹 사이트가 모두 HTTPS로 이루어져 있으면 대응할 사항이 없습니다. 그렇지 않다면 아래 사례를 확인이 필요합니다.
1) 내비게이션
지금까지는 HTTP 사이트와 HTTPS 사이트 사이의 내비게이션에서 Cookie를 보낼 수 있습니다. 하지만 Schemeful same-site가 적용된 후에는 HTTP 사이트와 HTTPS 사이트는 cross-site로 취급하게 됩니다. 이 때문에 Cookie의 SameSite 속성을 Strict로 설정해도 보낼 수 없습니다.
2) 서브리소스 / form의 POST 메소드
지금까지는 HTTP 사이트와 HTTPS 사이트 사이의 서브리소스와 form의 POST 메소드 요청을 통해 Cookie를 보낼 수 있습니다. 하지만 Schemeful same-site가 적용된 후에는 HTTP 사이트와 HTTPS 사이트는 cross-site로 취급하게 됩니다. 이 때문에 Cookie의 SameSite 속성을 Strict 또는 Lax로 설정해도 보낼 수 없습니다.
3) WebSocket
지금까지는 HTTP 사이트와 HTTPS 사이트에서 WebSocket와 WebSocket Secure 연결로 Cookie를 보낼 수 있습니다. 하지만 Schemeful same-site가 적용된 후에는 같은 보안성을 가진 경우에만 same-site로 취급하게 됩니다. 이 때문에 HTTP 사이트는 WebSocket에게만, HTTPS 사이트는 WebSocket Secure에게만 Cookie를 보낼 수 있습니다.
어떻게 대응할 수 있을까
1) 적용 시기
Chrome Platform Status에 따르면 Chrome M88부터 적용될 예정이며, Chromium Dash Schedule 를 보면 알 수 있듯이 Stable 버전은 2021년 1월 19일에 배포될 예정입니다.
2) 테스트 환경
Schemeful same-site를 테스트하기 위해서는 Chrome 86 이상 버전이 필요합니다. Chrome 86부터 chrome://flags에서 Schemeful Same-Site 를 Enabled로 설정하면 Schemeful same-site를 테스트할 수 있습니다.
3) 케이스별 대응 방법
HTTPS로 업그레이드 가능한 케이스
HTTPS로 업그레이드하는 것을 추천합니다. Chrome의 장기적인 계획은 third-party Cookie를 제거하고 개인정보 보호 대안으로 대체하는 것이기 때문에 Cookie의 속성을 변경하는 것은 임시조치입니다.
HTTPS로 업그레이드 불가능한 케이스
SameSite는 Lax로 설정합니다. 1) 내비게이션 경우에만 대응할 수 있고, 2) 서브 리소스 / form의 메소드, 3) WebSocket 경우는 HTTPS로 업그레이드하는 것 외에 해결 방법이 없습니다.
Set-Cookie: =; SameSite=Lax요약
- 변경사항과 목적이 무엇일까
- Schemeful same-site가 적용된 후에는 HTTP 사이트와 HTTPS 사이트를 cross-site로 취급함
- 주요 목적은 사이트 간 요청 위조 공격의 취약점을 해결하고 사용자를 보호하기 위함
- 확인이 필요한 부분
- 내비게이션, 서브리소스, form의 POST 메소드, WebSocket에 영향을 미치므로 대응 필요
- 어떻게 대응할 수 있을까
- Chrome 86부터 chrome://flags를 통해 테스트 가능
- HTTPS로 업그레이드 가능 할 때 HTTPS로 업그레이드 추천
- HTTPS로 업그레이드 불가능하고 1) 내비게이션 경우만 SameSite=Lax로 변경 후 해결
출처
- https://web.dev/schemeful-samesite/
- https://github.com/sbingler/schemeful-same-site
- https://chromestatus.com/feature/5096179480133632
