쿠키와 Iframe 으로 인한 트러블 슈팅 회고

원인

클라이언트사에 Iframe 에 embed 시킬 수 있는 전용 미니 웹페이지를 제공했다.
문제는 Iframe 에 embed 된 웹사이트에서 쿠키가 함께 사용되었다.
- 여기서 문제가 생겼다.
  - 쿠키는 자신이 사용되어야 할 곳을 도메인 으로 구분한다.
- Iframe 은 aaa.co.kr 도메인 내의 페이지를 보여준다.
- Iframe 을 보여주는 웹페이지 자체는 bbb.co.kr 이었다.
- aaa.co.kr 에서 bbb.co.kr 의 쿠키를 받으니 쿠키는 매 응답마다 왔지만 바로 버려졌다.
브라우저 내부에서 Iframe 으로부터 전달받은 쿠키를 그대로 사용하면 보안상 이슈가 생긴다.
- 브라우저 초창기에는 Iframe 으로부터 전달받은 쿠키를 그냥 사용했으나, 점차 이를 악용하는 피싱 사이트들이 생겨났다. 마음만 먹으면 얼마든지 악용할 수 있는 방식이었다.
- 결과적으로 구글 크롬은 보안상 이슈를 최소화하기 위해 Cookie 가 가진 SameSite 속성의 기본 값을 Lax로 설정하게 되었다.
  - 구글 크롬 공식 업데이트 포스팅 Feature: Cookies default to SameSite=Lax
- SameSite 의 기본 값이 Lax 로 설정되어, 도메인이 다른 경우엔 기껏 받은 인증 쿠키가 한번만 쓰고 버려졌다.

쿠키가 한번만 쓰고 버려지니, 서버는 쿠키에 할당할 값을 매 요청마다 만드느라 과도한 부하가 걸려버렸다.

Lax 란 보통 링크 (a 태그 등) 를 클릭해서 다른 사이트로 이동하는 경우에만 Cross-site requests 에 쿠키 사용을 허용한다.
- Strict 는 링크를 클릭해서 다른 사이트로 이동하는 경우에도 Cross-site requests 에 쿠키 사용을 허용하지 않는다.
Lax 도 링크를 클릭하는 것이 아닌, 소위 말하는 Third party embeds 에 대해서는 아예 Cross-site requests 에 쿠키 사용을 허용하지 않는다.
- Third party embeds 에는 image, iframe 등이 있다.
- 그 외에 자바스크립트를 이용한 form submit 등에 대해서도 쿠키 사용을 허용하지 않는다.

원래 쿠키는 보안상 외부에 공개될 수 밖에 없으므로, 외부에 노출되어도 되는 정보를 넣어놓아야 된다.
- 그래도 물론 세션 키 같은 것은 HttpOnly SameSite=Strict 와 같이 다양한 옵션으로 보호해두어야 한다.
그러나 이용자가 해외 IP 를 이용하는지는 보안에 중요하지 않은 정보이기 때문에, 이를 그냥 SameSite=None, Secure 처리해서 보관하기로 하였다.
- 해당 옵션을 주니, 더이상 whois API 를 모든 요청마다 반복적으로 호출하지 않아서 Iframe 에서도 딱히 네트워크 부하를 일으키지 않고 정상적으로 작동할 수 있게 되었다.

사실 SameSite=Lax 속성 하나만으로 이러한 문제가 생기진 않았다.
- 현재 웹사이트는 이용자의 IP가 해외 IP 인지 판단하여, 해외 IP 유저에게는 몇가지 별도 로직을 제공한다. 이게 문제였다.
이용자의 첫 웹사이트 접근에 해외 IP 여부를 판단하여 쿠키에 넣어두고, 해당 쿠키를 불러와 해외 유저에게 맞는 서비스를 제공한다.
이용자가 해외 IP 를 이용하는지 판단할 때는 whois 의 open API 서비스를 이용한다.
open API 서비스를 이용한다는 것은 whois 쪽으로 네트워크 요청을 보낸다는 뜻이다.
- 그런데 iframe 을 이용해 웹사이트를 불러오다보니 모든 리소스 로드에 필요한 HTTP 요청에 해외 아이피 여부를 묻는 API 요청이 들어가버렸다.
  - Iframe 내부에서는 수많은 js 파일과 수많은 css 파일 그리고 API 작업 요청이 일어났다.
  - 매 요청마다 국가를 묻는 whois API가 호출되었다.
  - 쿠키를 기억한다면, 단 한번만 진행 후에 더이상 진행하지 않았을 것이다.
모든 HTTP 요청에 해외 IP 여부를 묻는 API 요청이 들어가다보니 네트워크쪽에 과도한 부하가 생겼고, 이로인해 사내 웹 방화벽에서는 인스턴스를 LB에서 내려버리는 현상이 일어났다.