title

FE개발자의 성장 스토리 06 : 2021년 Chrome의 새로운 변화 – Schemeful same-site을 대응하자

안녕하세요. 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.nethttps://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로 변경 후 해결

 



출처

 

카카오톡 공유 보내기 버튼

Latest Posts

if kakao 2022 개발자 컨퍼런스를 개최합니다.

오래 기다리셨습니다. 카카오의 연례 개발자 컨퍼런스인 if(kakao) 2022를 12월 7일(수)~9일(금), 3일간 개최합니다. 공식 웹사이트(https://if.kakao.com) 및 카카오TV에서 온라인으로 진행되오니, 많은 참여와 관심 부탁드립니다.

(참여후기) 2022 부산대학교 정보컴퓨터공학부 산학교류회

안녕하세요, 카카오 광고추천팀 cory(최원영)입니다. 저는 부산대학교 정보컴퓨터공학부를 졸업하고, 현재는 카카오 광고추천팀에서 데이터엔지니어로 근무하면서 스트리밍 데이터를 분석하는 애플리케이션과 실시간 데이터 파이프라인 플랫폼을 개발

[post Server!] 브런치개발파트에 대한 모든 것!

브런치개발파트 채용시에 자주 나왔던 질문들에 대해서 답변하는 형식으로 브런치개발파트를 소개하려고 합니다.   브런치는 어떤 서비스인가요? 브런치는 작가가 글을 쓰고 그 글을 다양한