최근 1월 중순쯤부터 Chrome Samesite이슈에 대응한다고 설연휴전까지 시간이 굉장히 빠르게 지나간 것 같다.
아마 서비스에서 쿠키를 클라이언트들의 브라우저에 심어 무엇인가를 처리하고 있었던 분들이라면 해당 이슈에 대해 이미 파악하고 대처 했을 거라 생각된다. 그럼 구글에서 크롬(Google Chrome)에 어떤 정책을 적용했고 SameSite란 무엇인가? 에 대해 간단히 정리해보려 한다.
SameSite 한 마디로 지금 현재 사이트(도메인, First Party)의 쿠키만 클라이언트 브라우저에 심도록 허용하겠다!
이 말인 즉슨 기존 크롬 버전 80이전 버전에서는 도메인이 다른 (Third Party)의 서버에서 response.addCookie만 해주면 third party쿠키를 쉽게 심을 수 있었다. 관련한 내용은 이전 포스팅을 참고 바란다.
"다른 도메인 내부에 쿠키 생성하기(이게 가능해?)" https://brocess.tistory.com/146?category=715032
그렇다 이전에는 그냥 막 심어도 문제 없었다.
근데 구글에서 보안 이슈를 명목(사이트간 쿠키기반 요청 위조(CSRF - Cross site request forgery)으로 크롬(Google Chrome) 80버전 부터는 third party(웹서비스와 도메인이 다른 서버)에서 쿠키 심는걸 default로 막겠다는 것이다. 2020년 2월 4일 부터 점차 크롬을 사용하는 사용자들의 브라우저들이 79버전에서 80으로 자동으로 차차 업데이트 되어질거라고 말했었다.
이게 자기들 도메인의 웹서비스에 쿠키를 심어서 사용하는 서비스에는 별문제가 없겠지만 광고서비스와 같이 해당 클라이언트의 쿠키의 특정ID값을 기반으로 유저를 구분해 타겟팅하는 서비스들에서는 큰 이슈거리일 수 밖에 없다. 😱😱😱😱😱😱😱😱
하지만 구글에서는 아예 third party 쿠키를 심지못하도록 원천봉쇄하지는 않았다. 쿠키를 다른 도메인의 서비스에 심을 때 'SameSite=none', 'secure'설정을 쿠키에 하면 기존처럼 허용해주겠다는 것이다!!!! 크롬 버전 80이상부터는 기본적으로 크롬 브라우저의 설정이 'SameSite=Lax'가 되어 버린다. (Lax보다 한 단계 높은 보안 수준인 'strict'도 존재한다.)
그럼 어떤식으로 해결을 해주어야 할까?
크롬 Samesite설정을 강제적으로 80버전과 같은 보안수준으로 올리고 테스트를 해보았다. 해당 설정은 크롬 브라우저에 chrome://flags라고 치면 확인할 수 있다.
위의 Default값을 Enable로 변경하면 크롬 80버전의 SameSite의 상황을 재현할 수 있다.
따라서 이렇게 해놓고 테스트를 했을 때 기존에 클라이언트들의 브라우저에 심어놓았던 쿠키를 아예 읽어올 수 없게 되었다.😱😱😱😱
그럼 어떻게 해결을 했나?
일단 유저들의 크롬 브라우저가 80으로 업데이트 되기전 클라이언트들의 브라우저에 심긴 우리 서비스의 식별 ID값에 "samesite=none", "secure"설정을 하여 동일한 값으로 쿠키를 덮어씌워줘야 했다. but, "secure"설정이 된 쿠키는 "https"가 설정된 서버에서만 읽을 수 있기 때문에 수 많은 광고주나 매체주에 심겨 우리쪽 서버를 호출하는 url이 http로 되어있을 경우 읽지 못하는 문제가 발생할 수 있었다. 이에 서버 자체적으로 http로 들어오는 요청을 https로 리다이렉트 시키도록 하였다.
추가 검토사항으로는 구글이 크롬관련 작성한 문서에는 다음과 같이 씌어져 있다.
Versions of Chrome from Chrome 51 to Chrome 66 (inclusive on both ends).
These Chrome versions will reject a cookie with `SameSite=None`
즉, 크롬버전 51~66사이의 버전에서는 우리가 아무리 쿠키에 'SameSite=None', 'secure'설정을 한다고 하더라도 reject시켜 버린다는 것이다....
https://www.chromium.org/updates/same-site/incompatible-clients
그래서 어떡하지라는 생각이 들어 일단 우리 서비스에 요청오는 request들의 user-agent데이터를 기반으로 해당 버전에 속하는 요청이 얼마나 되는지 확인해보았다. 그랬더니 다행히도 해당 버전으로 부터 오는 요청은 1~2%내외였고 이 1~2%를 위해 무엇인가를 작업하기엔 trade-off가 되는 것들이 너무 많았다. 서버에서 하나 같이 user-agent의 버전을 확인해 해당 버전에서는 별도의 처리를 해주어야 했고 결국에 해당 버전에서 SameSite=None을 reject시켜버리기 때문에 손을 쓰기 힘든 상황이었기에 해당 버전을 위해 별도의 처리는 따로 하지 않기로 결정되었다.
그리고 스프링, 자바 어플리케이션에서 많이 사용하는 javax.servlet.http.cookie class에서는 SameSite관련 API를 지원하지 않기 때문에 SameSite속성을 추가하기 위해서는 HttpServletResponse 객체에 Set-Cookie헤더(header)를 추가해서 처리했어야 했다.
어플리케이션 사이드나 Web Server설정 관련해서 처리한 부분은 잘정리된 포스팅이 있어 해당 블로그를 참고하면 좋을 것 같다.👍(굉장히 잘 정리되어 있다.)
https://ifuwanna.tistory.com/223
작업을 하며 느낀점은....구글이 갑이다....지금도 구글의 영향력이 쌔지만 앞으로는 점점 더 그 파워가 막강해질것이다....그럼 구글 주식을 사야겠다😅......여기서 이만...
'Programming > Programming' 카테고리의 다른 글
운영체제 측면에서 Memory(메모리), Virtual Memory(가상메모리) (0) | 2020.02.19 |
---|---|
운영체제의 메모리 관련 주요 용어 개념 및 내용 (0) | 2020.02.18 |
브라우저(Browser)가 도메인에 해당하는 IP를 찾는 순서? (0) | 2020.02.08 |
Mac에서 IntelliJ사용할 때 많이 쓰는 Ctrl+Shift+a이슈(bug)? 팁(TIP)! (0) | 2020.02.07 |
[ shell script ] 하둡 디렉토리에서 최신 파일 가져오기 #get the latest hadoop file in directory (0) | 2019.11.29 |