월드컵 규모의 이벤트에서 메시지 전달이 가능했던 이유를 확인해 보세요 (Delivering Messages at the scale of the World Cup)
Google Pay의 최신 업데이트를 확인하세요 (What’s new in Google Pay)
*최신 개발자 문서에 대한 알림을 받아보려면, 여기에서 Google 개발자 프로필을 생성하여 손쉽게 살펴보세요. 다양한 개발자 학습 과정과 커뮤니티 이벤트에 참여하면 여러분의 프로필에 표시할 수 있는 온라인 인증 배지도 함께 드립니다.
Google for Developers
이 글은 SameSite 쿠키 속성 변경 사항을 다룬 시리즈 중 일부입니다.
Schemeful Same-Site는 (웹)사이트의 정의를 단순히 등록 가능한 도메인에서 스킴 + 등록 가능한 도메인으로 바꿉니다. 'same-site'와 'same-origin'의 이해에서 자세한 설명과 예시를 찾을 수 있습니다.
주요 용어: 이는 사이트의 보안에 취약한 HTTP 버전(예: http://website.example)과 보안이 강화된 HTTPS 버전(예: https://website.example)이 이제는 서로에게 교차 사이트로 간주된다는 의미입니다.
여러분의 웹사이트가 이미 HTTPS로 완전히 업그레이드된 상태라면 영향이 없어 걱정할 필요가 없습니다. 웹사이트를 아직 완전히 업그레이드하지 않았다면 이 문제부터 우선적으로 해결해야 합니다. 하지만 사이트 방문자가 HTTP 사이트와 HTTPS 사이트 간에 이동하는 사례가 있는 경우 그처럼 흔히 일어나는 상황과 관련 SameSite 쿠키 동작에 관해 아래에 간략히 설명합니다.
경고: 장기 계획은 타사 쿠키에 대한 지원을 단계적으로 완전히 중단하고 이를 대체 쿠키를 유지하는 개인정보 보호 기능으로 바꾸는 것입니다. 스킴 간에 전송할 수 있도록 쿠키에 대해 SameSite=None; Secure를 설정하는 것은 HTTPS로의 완전한 마이그레이션에서 임시 솔루션으로만 생각해야 합니다.
이런 변경 사항을 사용해 Chrome과 Firefox에서 모두 테스트할 수 있습니다.
Chrome 86부터는 chrome://flags/#schemeful-same-site를 사용합니다. Chrome Status 페이지에서 진행 상황을 추적하세요.
Firefox 79부터는 about:config를 통해 network.cookie.sameSite.schemeful을 true로 설정합니다. Bugzilla 문제를 통해 진행 상황을 추적하세요.
쿠키에 대한 기본값으로 SameSite=Lax로 변경하는 주된 이유 중 하나는 CSRF(교차 사이트 요청 위조)로부터 보호하기 위함이었습니다. 하지만 네트워크 공격자가 여전히 쿠키를 변조해 나중에 사이트의 보안 HTTPS 버전에서 사용할 기회로 비보안 HTTP 트래픽을 악용할 수 있습니다. 스킴 사이에 이런 교차 사이트 경계를 추가로 만들면 위와 같은 공격에 대한 추가적인 방어 수단이 됩니다.
주요 용어: 아래의 예에서 URL이 모두 동일한 등록 가능 도메인(예: site.example)을 가지고 있지만 스킴은 서로 다르며(예: http://site.example과 https://site.example), 이를 교차 스킴이라고 합니다.
웹사이트의 교차 스킴 버전 간 탐색(예: http://site.example에서 https://site.example로 연결)에서는 이전에 SameSite=Strict 쿠키 전송을 허용했습니다. 이제는 이것을 교차 사이트 탐색으로 처리합니다. 즉, SameSite=Strict 쿠키가 차단될 것이라는 뜻입니다.
HTTP에서 HTTPS로의 교차 스킴 탐색.
경고: 모든 주요 브라우저는 스크립트나 iframe과 같은 능동 혼합 콘텐츠를 차단합니다. 또한 Chrome과 Firefox를 포함한 브라우저는 수동 혼합 콘텐츠를 업그레이드하거나 차단하는 쪽으로 작동합니다.
여기서 변경하는 사항은 모두 완전한 HTTPS로 업그레이드하기 위한 작업을 하는 동안의 일시적 수정으로만 생각해야 합니다.
하위 리소스의 예로는 이미지, iframe 그리고 XHR이나 Fetch로 수행되는 네트워크 요청 등을 들 수 있습니다.
이전에는 웹페이지에서 교차 스킴 하위 리소스를 로드하면 SameSite=Strict 또는 SameSite=Lax 쿠키 전송이나 설정이 허용되었습니다. 이제는 다른 모든 타사 또는 교차 사이트 하위 리소스와 똑같은 방식으로 처리되는데, 이는 곧 어떤 SameSite=Strict 또는 SameSite=Lax 쿠키라도 차단될 것이라는 뜻입니다.
또한 브라우저에서 비보안 스킴의 리소스가 보안 페이지에 로드되는 것을 허용한다 하더라도, 타사 쿠키나 교차 사이트 쿠키에 Secure가 필요하므로 이러한 요청에 대해 모든 쿠키가 차단될 것입니다.
HTTPS를 통한 교차 스킴 하위 리소스를 포함한 HTTP 페이지.
이전에는 웹사이트의 교차 스킴 버전 간에 게시할 경우 SameSite=Lax 또는 SameSite=Strict로 설정된 쿠키 전송이 허용되었습니다. 이것은 이제 교차 사이트 POST로 처리되므로 SameSite=None 쿠키만 전송 가능합니다. 기본적으로 비보안 버전을 제공하는 사이트에서 이런 상황이 발생할 수 있지만, 로그인 또는 체크아웃 양식 제출 시 사용자를 보안 버전으로 업그레이드할 수 있습니다.
하위 리소스와 마찬가지로, 보안(HTTPS) 컨텍스트에서 비보안(HTTP) 컨텍스트로 요청이 이루어질 경우에는 타사 쿠키나 교차 사이트 쿠키에 Secure가 필요하므로 이런 요청에 대해 모든 쿠키가 차단됩니다.
경고: 여기서 최선의 해결책은 양식 페이지와 대상에서 모두 HTTPS와 같은 보안 연결을 보장하는 것입니다. 이는 특히 사용자가 민감한 정보를 양식에 입력할 경우에 중요합니다.
HTTP에서 HTTPS로의 교차 스킴 양식 제출.
Chrome과 Firefox에서는 개발자 도구와 메시징이 제공됩니다.
Chrome 86부터는 DevTools의 Issue 탭에 Schemeful Same-Site 문제가 포함됩니다. 사이트에 대해 다음과 같은 문제가 강조 표시되는 모습이 보일 수 있습니다.
탐색 문제:
'동일 사이트 요청에 대해 쿠키가 계속 전송되도록 하기 위해 완전히 HTTPS로 마이그레이션'—쿠키가 Chrome의 이후 버전에서 차단될 예정이라는 경고.
'동일 사이트 요청에 대해 쿠키가 전송되도록 하기 위해 완전히 HTTPS로 마이그레이션'—쿠키가 이미 차단되었다는 경고.
하위 리소스 로드 문제:
'동일 사이트 하위 리소스로 쿠키가 계속 전송되도록 하기 위해 완전히 HTTPS로 마이그레이션' 또는 '동일 사이트 하위 리소스에 의해 계속해서 쿠키가 설정되도록 허용하기 위해 완전히 HTTPS로 마이그레이션'—쿠키가 Chrome의 이후 버전에서 차단될 예정이라는 경고.
'동일 사이트 하위 리소스로 쿠키가 전송되도록 하기 위해 완전히 HTTPS로 마이그레이션' 또는 '동일 사이트 하위 리소스에 의해 쿠키가 설정되도록 허용하기 위해 완전히 HTTPS로 마이그레이션'—쿠키가 이미 차단되었다는 경고. 후자의 경고는 양식을 POST할 때 나타날 수도 있습니다.
Schemeful Same-Site를 위한 테스트 및 디버깅 팁에서 자세한 내용을 확인할 수 있습니다.
Firefox 79부터는 about:config를 통해 network.cookie.sameSite.schemeful을 true로 설정하면 콘솔에 Schemeful Same-Site 문제에 대한 메시지가 표시됩니다. 사이트에 다음과 같은 메시지가 표시될 수 있습니다.
'스킴이 일치하지 않으므로 cookie_name 쿠키가 http://site.example/에 대해 곧 교차 사이트 쿠키로 처리됩니다.'
'스킴이 일치하지 않으므로 cookie_name 쿠키가 이미 http://site.example/에 대한 교차 사이트로 처리되었습니다.'
링크와 하위 리소스 중 일부가 여전히 비보안 URL을 가리킬 가능성이 있습니다.
이 문제를 수정하는 한 가지 방법은 HSTS(HTTP Strict-Transport-Security)와 includeSubDomain 지침을 사용하는 것입니다. 페이지 중 하나에 우연히 비보안 링크가 포함되어 있더라도 HSTS + includeSubDomain을 사용하면 자동으로 브라우저에서 보안 버전을 대신 사용하게 됩니다.
사용자 보호를 위해 사이트를 완전히 HTTPS로 업그레이드할 것을 강력히 권장하지만, 스스로 업그레이드할 수 없다면 호스팅 공급자에게 문의해 그런 옵션을 제공할 수 있는지 알아보시기 바랍니다. 스스로 호스트하는 경우에는 인증서를 설치하고 구성할 수 있는 여러 가지 도구를 제공하는 Let's Encrypt를 이용해보세요. 또한 CDN이나 HTTPS 연결 기능을 제공할 수 있는 다른 프록시 뒤로 사이트를 이동하는 방법을 알아볼 수도 있습니다.
그 방법 역시 가능하지 않다면 해당 쿠키에 대한 SameSite 보호 수준을 완화해보세요.
SameSite=Strict 쿠키만 차단되는 경우 보호 수준을 Lax로 낮출 수 있습니다.
Strict 쿠키와 Lax 쿠키가 모두 차단되고 쿠키가 보안 URL로 전송되거나 보안 URL에서 설정되는 경우에는 보호 수준을 None으로 낮출 수 있습니다.
쿠키를 전송하는 대상 URL이나 쿠키를 설정하는 소스 URL이 비보안이면 이 임시 해결책이 실패하게 될 것입니다. 그 이유는 SameSite=None은 쿠키에 Secure 속성이 필요하며, 이는 비보안 연결을 통해서는 해당 쿠키를 전송하거나 설정할 수 없다는 뜻이기 때문입니다. 이 경우에는 사이트를 HTTPS로 업그레이드해야 그 쿠키에 액세스할 수 있습니다.
결국에는 타사 쿠키에 대한 지원이 단계적으로 완전히 중단될 것이므로 이는 임시 방편일 뿐임을 기억하세요.
SameSite 속성이 없는 쿠키는 SameSite=Lax를 지정해 동일한 교차 스킴 동작이 이 쿠키에도 적용되는 것처럼 처리됩니다. 안전하지 않은 방법에 대한 일시적 예외가 여전히 적용됩니다. 자세한 내용은 Chromium SameSite FAQ에서 Lax + POST 완화를 참조하세요.
WebSocket 연결은 페이지와 동일한 보안 수준이라면 계속 동일 사이트로 간주될 것입니다.
동일 사이트:
https://에서 wss:// 연결
http://에서 ws:// 연결
교차 사이트:
http://에서 wss:// 연결
https://에서 ws:// 연결
사진: Julissa Capdevilla(Unsplash에서 발췌)
