chrome80 바뀐 cookie 정책 대응하기 ( SameSite=none)

chrome80

크롬 80버전부터 새로운 쿠키 정책(SameSite Cookie)이 시행될 예정이다.
이 정책이 시작되면 어떤 영향도가있는지, 어떻게 대응해야할지 알아보자

바뀐 쿠키정책

목적

CSRF ( cross-site-request-forger ) 공격을 막기 위해 third-party 쿠키를 막으려는것이 기본 컨셉이다. 이를 위해 cookie 정책중 samesite의 기본값을 바꾼다. 하지만 이렇게되면 오류가 매우 많이 발생할수 있으니 top-level navigation일 경우에는 third-party cookie를 허용해주는 Lax를 기본값으로 한다.
chrome79 에서는 samesite 기본값이 None으로 되어있으나 chrome80 부터는 Lax가 된다.

영향도

cookie값을 읽는데 영향이 생긴다. cookie값은 서로다른 사이트에서 정보를 주고받는데 많이 사용한다.
대표적으로는 로그인과 사용자 식별을 예로 들 수 있다. 많은 사이트들이 쿠키에 로그인에 대한 정보를 담은 token값을 저장하고, 이값으로 로그인여부판단과 사용자식별을 한다.
만약 cookie값을 읽지 못한다면 로그인후 셋팅된 token값을 읽지못해 로그인이 실패하는 현상이 생길것이다. 그럼 samesite가 무엇이고, 어떤 정책을 가지고있는지 그리고 chrome80에서 주의할점을 알아보자

시기

2020년 2월 4일부터 Chrome 80 배포 예정이다.
이 전에 대응해야 업데이트한 사용자에게 서비스를 정상적으로 제공 할 수 있다.

SameSite Cookie

cookie 를 읽을수 있는 대상을 명확하게 하는것이 주 목적이라고 볼 수 있다.
정책별로 어떤점이 다른지 알아보자

SameSite	정의	chrome 80이후 버전 주의점
Strict	사용자가 직접 주소창에 입력하는 top-level navigation을 제외한 모든 요청에 Cookie가 포함되지 않는다. 즉, Strict는 쿠키를 사이트 간에 사용할 수 없게 차단합니다. 이 옵션은 은행과 같이 보안이 높은 애플리케이션에 가장 적합합니다.	link, Form Get, Form Post, iframe, ajax, img를 통해 다른 domain request 요청시 쿠키 전달 안됨 ex) Form Post b.com에서 쿠키가 구워진 상태에서 a.com site에서 Form Post로 b.com으로 submit할때 b.com의 http request에서 쿠키를 읽을 수가 없다.
Lax	Cookies with this setting are sent only on same-site requests or top-level navigation with non-idempotent HTTP requests, like HTTP GET 따라서 이 옵션은 타사에서 쿠키를 사용할 수 있지만 CSRF 공격의 피해를 당하지 않도록 하는 보안 혜택이 추가된 경우에 사용됩니다.	chrome 80 부터 Default Form Post, iframe, ajax, img를 통해 다른 domain request 요청시 쿠키 전달 안됨 : 사용자가 주소창에 주소가 변경되는걸 확인 할 수 있는 경우만 쿠키 전달을 허용하는 것으로 이해됨 ex) iframe b.com에서 쿠키가 구워진 상태에서 a.com에서 b.com site를 iframe으로 포함할 경우 b.com의 쿠키를 iframe인 b.com에서 읽을 수가 없다.
None	기존에 사용하던 Default설정	Cookies without SameSite must be secure 설정이 enable상태에서 Secure특성을(https강제) 태깅하지 않으면 쿠키를 전달하지 않습니다.(다른 도메인을 가진 iframe내에서는 lax나 strict는 신규로 구워지지 않음) https://www.chromium.org/updates/same-site/incompatible-clients safari MacOS 10.14의 Safari 및 내장 브라우저 및 iOS 12의 모든 브라우저 SameSite = None`으로 표시된 쿠키를`SameSite = Strict`로 표시된 것처럼 잘못 취급합니다. 이 버그는 최신 버전의 iOS 및 MacOS에서 수정되었습니다 chrome Chrome 51에서 Chrome 66까지의 Chrome 버전 (양쪽 모두 포함) 이 Chrome 버전은`SameSite = None`의 쿠키를 거부합니다. 이는 Android WebView뿐만 아니라 이전 버전의 Chromium 파생 브라우저에도 영향을줍니다 Chrome 51 이전에는 SameSite 속성이 완전히 무시되었으며 모든 쿠키는 마치 ‘SameSite = None’으로 취급되었습니다.

더 자세한 내용은 아래 링크를 참고하자

• https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
• https://docs.adobe.com/content/help/ko-KR/target/using/implement-target/before-implement/privacy/google-chrome-samesite-cookie-policies.translate.html

대처법

정책정하기

가장 먼저 할 일은 정책을 정하는것이다.
SameSite설정이 없는 경우 Lax가 Default 설정이 된다.
위 sameSite 설정에관한 내용을 읽어보고 자신이 하고있는 서비스의 쿠키정책을 Lax로 할것인지, None으로 할것인지 의논하여 정하자

SameSite None

chrome80 이 점차적으로 보급됨에따라서 Cookies without SameSite must be secure 설정이 점차적으로 상승할것이다.
None으로 사용하고싶다면 모든 요청을 https인지 점검하고 Secure tag를 꼭 함께 사용해야 합니다..
None을 더이상 사용하지 않겠다면 Default 설정이 될 Lax의 내용을 확인하자

SameSite Lax

같은 Domain설정을 사용한다면 문제가 되지 않는다 (ex: *.domain.com를 사용하는 모든 sub domain)
다른 domain(shop.com)을 사용하는 곳에서 쿠키를 구운 도메인(id.com)을 호출하는 경우 shop.com에서 id.com을 호출하는 방식에 따라서 브라우저가 id.com에 이전에 구워 놓은 쿠키를 전달하지 않는다.

추가적으로 쿠키를 다음 방식으로 호출시 쿠키값을 전달하지 않는다

• Form Post
• iframe
• ajax
• img

대표적인 예로는 쇼핑몰에서 소셜회원으로 로그인을 한다면, 소셜서비스 도메인의 페이지에서 회원인증후 쿠키를 굽고, 이후 쇼핑몰에서 그 쿠키를 확인하는 방식으로 동작할것이다. 이경우 쿠키를 읽는데 실패할것이다.

SameSite strict

Lax와 동일하지만 쿠키를 전달하지 않는 호출 방식이 다양하다.

• Link
• Form Get
• Form Post
• iframe
• ajax
• img

대처법

sub domain으로만 서비스 하는 경우는 Lax정책이 default가 되더라도 큰 영향이 없다.
다른 도메인 서비스와 정보를 주고받는 경우 SameSite 정책을 None으로 가져가야하며, 이 쿠키를 사용하는 모든 서비스에서는 이에 대응해야한다

쿠키를 굽는 서비스

쿠키를 구울때 SameSite=None 옵션을 주어서 굽도록 한다

쿠키를 읽는 서비스

https 통신하기

https통신을 하는 경우만 쿠키값을 읽을수 있으므로 모든서비스가 https통신을 할 수 있게 준비해야한다. 저자가 담당하는 서비스에서는 크게 2가지로 나누어 대응하였다

1. apache / nginx 에서 http로 요청시 https로 redirect

우선은 모든 서비스가 쿠키값을 읽을 수 있도록 https서비스를 하도록 하였다.

2. image file, 등 static resource를 상대경로로 바꾸기

모든서비스가 https 로 동작하게되기때문에 리소스에 http로 절대경로가 적혀있다면 오류가 발생할 수 있다. 때문에 모든 리소스의 주소를 상대경로로 바꾸었다