👩💻 프론트 : 쿠키가 오긴하는데 Set-Cookie가 뭔가 이상해요
프로젝트 초반에 위의 문제 상황이 있었고 이를 sameSite=None, domain={도메인} 으로 해결했다. 크롬의 기본 설정값인 sameSite=Lax 가 서로 다른 도메인간의 쿠키 전송을 제한했기 때문에 프론트와 백엔드간의 통신을 위해 sameSite=None 으로 지정했다. 그런데 크롬에서는 왜 Lax를 기본값으로 설정했을까? 프론트-서버 통신에서는 Lax를 사용하지 못하는 것일까? 뭔가 잘못 이해하고 있다는 생각이 들어 다시 공부하며 개념을 정리했다.
결론 → Site, Origin, Domain은 다른 개념이다.
웹 보안을 위한 쿠키 옵션
먼저, 웹 보안 문제와 쿠키 옵션에 대해 정리해보자. 웹 보안 문제로 가장 많이 언급되는 것은 XSS, CSRF 공격이다.
XSS(Cross-Site-Scripting) 공격
공격자가 웹 페이지에 악성 스크립트를 삽입하여 사용자의 브라우저에서 실행되게 만드는 공격이다. 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 발생한다. 결과로 사용자는 의도치 않은 동작을 수행하거나 쿠키, 세션 등의 정보를 탈취당하게 된다. 악성 스크립트를 삽입한다는 것이 잘 이해가 안 되서 XSS 공격의 예제 코드를 보면서 이해했다. 쿠키의 httpOnly 옵션을 통해 자바스크립트로(document.cookie) 쿠키에 직접 접근해서 쿠키 정보를 읽어오는 것을 방지할 수 있다.
CSRF(Cross-Site-Request-Forgery) 공격
사용자가 자신의 의지와 무관하게 공격자가 의도한 행위를 서버에 요청하게 만드는 공격이다. 사용자의 권한을 이용해 서버에 대한 악성 공격을 한다. 예를 들어 공격자가 자신에게 돈을 송금하도록 송금 전송에 대한 요청을 조작하고자 한다. 공격자는 송금 전송에 대한 스크립트를 삽입한 링크를 게시판이나 메일을 통해 사용자에게 노출시킨다. 사용자가 해당 링크를 클릭하는 순간 요청이 서버로 전달되고 서버는 사용자를 신뢰하기 때문에 공격자에게 돈을 송금한다. XSS 요청은 사용자가 특정 사이트를 신뢰하기 때문에 발생하는 문제라면, CSRF는 특정 사이트가 사용자를 신뢰하기 때문에 발생하는 문제이다. 쿠키의 sameSite 옵션을 통해 다른 사이트에서의 요청을 차단할 수 있다.
쿠키의 SameSite 옵션
SameSite는 크게 3가지 옵션이 존재한다.
- Strict : 반드시 같은 사이트에서만 사용 가능하다.
- Lax : 같은 사이트에서 사용 가능하지만, 유저가 링크를 클릭해서 접속하거나 하는 경우에는 다른 사이트에서 사용 가능하다.
- None : 다른 사이트에서도 사용 가능하지만 반드시 Secure 옵션과 함께 사용해야 한다.
크롬의 Same-Site-Policy
Third-Party Cookie라는 개념이 있다. 요청을 보내는 쪽과 받는 쪽의 사이트가 다른 경우를 가르켜 3자 쿠키라고 한다. 구글 크롬에서는 2020년 쿠키의 기본 동작에 대한 변경을 발표했는데, 과거에는 아무런 옵션을 지정하지 않아도 다른 사이트에서 쿠키를 보낼 수 있었다. 하지만 이제는 3자 쿠키를 사용하려면 반드시 SameSite=None 옵션과 Secure라는 옵션을 쿠키에 설정해 주어야 한다. 또한 지정하지 않으면 기본 설정은 SameSite=Lax이다.
그런데, 사이트(Site)가 도대체 무슨 개념인가?
아까부터 사이트, 사이트하는데 domain, origin이란 비슷한 개념인가?
많은 글에서 Site를 단순히 도메인으로 치환해서 글을 작성해서 사이트와 도메인이 같은 개념이라고 생각했다. 그래서 dev-fe.example.com → dev.example.com 으로 요청을 보내면 다른 사이트로 생각했다. 하지만 사이트는 도메인과 최상위 도메인을 포함하는 개념이다. 위의 두 도메인은 서브 도메인이 다르지만 도메인과 최상위 도메인이 같기 때문에 같은 사이트라고 판단하는 것이다. 그리고 Origin(출처)가 같다는 것은 프로토콜, 도메인, 포트까지 포함하는 개념이다.
두 사이트가 sameSite인지는 개발자 도구를 통해서도 확인할 수 있다. 같다면 same-site, 아니라면 none이라는 값이 뜬다.
처음에 프론트가 Set-Cookie가 이상하다고 말한 것도 브라우저 환경이 아닌 로컬 환경에서 확인했을 때였다. 쿠키 설정은 아래와 같았다.
ResponseCookie.from("token", "{토큰값}")
.httpOnly(true)
.path("/")
.build();프론트의 로컬 환경(localhost)와 dev.bang-ggood.com 이 서로 다른 사이트였기 때문에 쿠키가 제대로 설정되지 않아 작업을 진행할 수 없었다. 배포환경에서 확인했다면 쿠키가 잘 저장되었을 것이다.
추가로, Domain 옵션도 알아보자
Domain 옵션은 요청을 보낼 호스트를 지정하는 것이다. 따로 설정하지 않으면 기본으로 쿠키를 생성하는 서버의 도메인으로 설정한다. 여기서는 도메인을 설정하지 않은채 쿠키 전송을 했더니 서버 도메인이 찍히는 걸 볼 수 있다.
쿠키 도메인 설정과 실제 도메인이 다르다면 쿠키 저장을 거부하는 듯하다. 처음에 Domain 옵션을 제대로 이해하지 못해 dev-fe 도메인을 설정했더니 쿠키가 제대로 저장되지 않는 문제가 있었다.
결론
PROD 환경에서는 sameSite=Lax로 설정하고, DEV 환경에서는 sameSite=None으로 설정하자
이전에는 DEV, PROD 환경 모두 sameSite=None으로 두었다. 이번에 새롭게 공부하며 보안을 위해 PROD에서는 sameSite=Lax으로, DEV에서는 개발 환경을 위해 None으로 지정하는 것이 더 좋은 방식임을 알게 됐다.
