SameSite Cookie속성 변경? 정책 3가지/이유/대응 (Chrome80 업데이트)

chrome80버전 부터 same-site속성에 대한 정책이 Lax로 변경되는 등 몇가지 정책 변화가 생겼다.  크롬 브라우저의 점유율이 50%가 넘는 만큼 무시할 수 없는 변화다.  

 

어떤 변경이 있고 어떻게 대응해야하는지 알아보자!

 

응 혼란스러워

 

---

SameSite 속성에 대해 변경되는 정책

1. 쿠키를 구울 때 SameSite옵션이 없는경우 Lax로 간주한다.

2. SameSite=none 으로 사용하려면 secure옵션(https요청만 허용) 을 필수로 한다  

3. http와 https간의 연결은 Cross-site로 간주한다. (schemeful same-site)

 

---

 

 

 SameSite 옵션이란?

쿠키의 사용 범위를 제한하기 위한 쿠키 옵션. (외부 Access방지. java의 private public같은 접근제한자 역할)

종류	(접근정책 유연>강력 순)
None	도메인 검증하지 않음.(타사에서 접근가능) secure옵션(https만 접근가능)을 설정해야한다. 설정시 None,Lax,Strict가 아닌값으로 설정할 경우 None으로 처리됨.
Lax	자사도메인이 아니더라도 일부케이스(링크를 클릭해 이동하는 경우 등) 에서는 접근을 허용하겠다. (상태를 변경하는 요청인 POST요청시 접근 불가)
Strict	자사 도메인으로만 쿠키전송 가능 (현재 브라우저의 URL과 쿠키의 도메인 일치하는경우)

* Lax와 Strict는 보안상 완전한 해결책이 아니므로 해당 옵션을 주더라도 보안이 필요한 데이터는 저장하지 마시오 *

 

* Lax 정책 이해를 위한 예시  *

사내 System에 로그인 후 강의신청을 클릭하면  a태그를 통해 외부 강의 사이트로 랜딩된다. 로그인관련 암호화 값은 쿠키를 사용해 공유한다.

 

이 때, 로그인 쿠키가 

- Lax라면? 외부 강의 사이트에서 쿠키 접근이 가능하다.

- Strict라면? 자사도메인 쿠키가 아니므로 접근불가능하다.

사내 시스템에 로그인을 했음에도 외부강의 사이트가 쿠키에 접근하지 못해 비로그인으로 판단하게 된다.

 

예시 참고 

tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00#section-5.2

 

기타 다른 옵션들? (TO-DO)

 

 

 

 SameSite (자사도메인) 의 기준?

[도메인 접미사 와 도메인 접미사 바로 앞 도메인]이 같다면 Same-Site.

예) ww.web.dev/ static.web.dev 는 "web.dev"라는 사이트의 일부로 Same-Site

 

하지만, public접미사 (.com, github.io등) 의 경우 [접미사+접미사 앞 도메인] 이 같아도 Cross-Site.

예) your-project.github.io / my-project.github.io 는 Cross-Site

      aa.myproject.com / bb.myproject.com 은 Same-Site

 

public접미사 list : publicsuffix.org/list/public_suffix_list.dat

 

 

 

 SameSite기준에 부합하는데 Access가 안되는 경우?

도메인 기준이 맞아도 scheme이 맞지않으면 (http <> https) cross-site로 간주하는 Chrome 설정 옵션이 있다.

SameSite Cookie속성 변경? Schemeful Same-Site (Chrome80)

 

 

 

 

 

 왜 SameSite Default옵션 None > Lax로 변경 했나?

 

1. 보안 및 개인정보 보호 문제

    >> 쿠키 수정/조회가 쉬워 CSRF 공격에 취약하고, 쿠키를 털어서 사용자의 활동을 추적하는등 문제가 발생한다.

2. 쿠키가 많아지면 Request에 쓸데없는 오버헤드가 발생한다 

   >> 궁금하지도 않은 남에쿠키 왜들고 다녀야 하나

 

결론

쿠키의 사용처를 명확하게 함으로써 위의 정보 유출 위험을 완화하고, CSRF를 일부 보호하고, 오버헤드 문제를 해결하겠다.

 

CSRF? (TO-DO)

 

 

 

 

 정책 변경 후 영향성을 확인해야하는 부분 ? 

1. cross-site에서 쿠키를 사용할 수 있어야 하는 경우 (광고, 제휴등의 쿠키)

    >> 쿠키를 생성할 때 samesite=none, secure 옵션을 넣어야한다.

2. 쿠키 생성시 SameSite=none 옵션만 넣고 secure옵션은 넣지 않은 쿠키가 있는지

    >> secure옵션도 넣어주자.

3. http 페이지에서 쿠키를 담아 https를 호출해야 하는 경우 

    >> 호출페이지를 https페이지로 변경해야한다 

 

 

 

 SameSite=none, secure 설정 쿠키굽기

Cookie 생성하기 (SameSite Cookie 이슈 대응) - java

 

 

 

 SameSite=none 동작을 처리 못하는 브라우저가 있다.

None값은 Chrome67 이상에서 추가된 기능으로 일부 Client(Chrome66이하, AndroidWebView등 )에서 해당옵션을 처리하지 못한다.

오피셜 블로그에는 samesite=none;secure 옵션이 있는 쿠키(새 스타일)와 없는 쿠키(레거시 스타일)  둘다 구워서 새스타일 쿠키가 있는지 확인하고 찾을 수 없는경우 레거시 쿠키로 대체하라고 한다.

 

옵션 호환되지 않는 Client : www.chromium.org/updates/same-site/incompatible-clients

SameSite=None: Known Incompatible Clients - The Chromium Projects

 

 

 테스트-디버깅 방법

www.chromium.org/updates/same-site/test-debug

Tips for testing and debugging SameSite-by-default and “SameSite=None; Secure” cookies - The Chromium Projects

 

 

 

 Chrome을 시작으로..

chromium블로그에 의하면 Mozilla와 MS도 자체 일정에 따라 Firefox 및 Edge에서 구현할 의사를 표시 했다고 한다.

 

 

 

 

 

---

(궁금할 수도 있는 사전 지식)

쿠키란 무엇이며 왜 사용하는가? cherish-it.tistory.com/9

http와 https의 차이는 ? (TO-DO)

 

 

(참고 링크)

web.dev/samesite-cookies-explained/

web.dev/samesite-cookie-recipes/

samesite-sandbox.glitch.me/

www.chromium.org/updates/same-site

blog.chromium.org/2019/10/developers-get-ready-for-new.html

tools.ietf.org/html/draft-west-cookie-incrementalism-00

 

experienceleague.adobe.com/docs/target/using/implement-target/before-implement/privacy/google-chrome-samesite-cookie-policies.html?lang=ko-KR#google%EC%9D%98-%EB%B3%B4%EC%95%88-%EB%AA%A8%EB%B2%94-%EC%82%AC%EB%A1%80%EB%A5%BC-%EB%94%B0%EB%A5%B4%EB%8A%94-target