과거 해당 크로스 사이트에 접속해서 얻은 로그인 인증 정보가 함께 전달돼 크로스 사이트(비의도)공격
CSRF 공격으로 크로스 사이트(비의도) 요청 시 크로스 사이트에 과거에 설정됐던 쿠키가 전송 (크로스사이트에 과거에 설정됐던 쿠기 = 서트파트 쿠키)
💡SameSite 옵션 이해를 위한 중요 개념: 퍼스트파트 쿠키 & 서드파트 쿠키 설명 및 에시 그림 퍼스트파티, 서드파티 판다는 Stie Domain과 Cookie Domain의 일치여부로 결정 1. Site Domain: 현재 유저(내)가 보가 있는 웹 브라우저 창에 뜬 도메인명 2.Cookie Domain: 쿠키에 설정되어 있는 Domain + Path값에 명시된 도메인명
🔹퍼스트파트 쿠키 -cookie domain = site domain 현재 도메인에서 필요에 따라 생성/저장한 로그인 인증과 같은 개인화 정보 인식용 쿠키 🔹서드파트 쿠키 - cookie domain != site domain 많은 홈페이지들을 오가며 유저의 행동을 기록 및 추척하기 위한 Goolge Ads 정보 수집
실제 현업에서의 퍼스트파트 쿠키와 서드파트 쿠키의 예시는 어떤지 살펴보자(오늘의 집) cookie에 퍼스트파트 쿠키(ohou.se)와 서트파트 쿠키(td.douvleclick.net)이 있다. HTTPS사용해도 = 서드파트 쿠키가 로그인, 인증정보를 담고 있다면 어드민 API호출도 가능 - 전체 유저 정보 조회, 대량 삭제 권한이 필요한 API 호출이 인증 정보 쿠키로 손쉽게 가능 HTTPS 미사용시 = MITM로 요청을 가로챈다면 서드파트 쿠키를 외부에서 볼 수 있다.
그래서 크로스 사이트 요청 시 크로스 사이트에 해당하는 쿠키라 할지라도 CSRF공격으로 인해 쿠키 탈취될 위험이 있으므로 전송되지 않게 막을 필요가 있다. 이걸 해주는 쿠키 설정이 Same site이다.
same site옵션은 크로스사이트 요청시 보안 레벨을 설정해서 서드파트 쿠키를 담아?말아?를 결정해준다.
[same site 보안 레벨]
보안 레벨 높음: Strict: 퍼스트파티 쿠키만 전송 허용
그러면 서드파트 쿠키가 필요한 경우 어떻게 쿠키 정보를 전송해야하나? 웹 브라우저와 same site인 서버에 요청을 보내고 해당서버에서 서드파트쿠키 서버를 호출한다.
보안 레벨 중간: Lax: 서트파트 쿠키라도 특수 케이스시엔 부분 허용
보안 업데이트 후 최신 크롬 default값
특수 케이스 = 상태 서버 변경하지 않고 조회만: `GET`, `<a href>`, `<link rel="prerender">`
보안 레벨 낮음: None: 서드파트 쿠키 모두 허용
보안 업데이트 전 과거 크롬 default값
단, Secure 설정을 강제하여, HTTPS 미사용시 MITM 탈튀에 대한 문제 방지
💡google.api가 채번해서 유저 FootPrint 추적하기 Q. same site=strict일때, goole.api가 채번을 해주더라도 브라우저에서 google.api 로 서드파트 쿠키를 보내지 못하여 유저가 어떤 행동을 했는지 정보를 수집할 수가 없습니다. 그래서 google.api의 채번 역할을 same origin인 서버가 대신 해주고 그걸로 유저의 footPrint를 수집한 후, 수집한 정보를(same origin) 서버에게 넘겨주고, 이 정보를 받은(same origin)서버가 google .api를 호출(서버끼리는 CSRF가 발생하지 않아서)해서 정보를 넘겨주는 방식인가요? A. 맞다
