쿠키와 세션, 그리고 쿠키의 옵션들에 대하여

1. 쿠키란?

쿠키는 사용자의 브라우저에 저장되는 작은 문자열로 최대 4KB까지 저장될 수 있다. HTTP는 무상태성(stateless)이란 특징을 가지고 있는데, 따라서 서버는 두 요청이 같은 브라우저에서 오는지 알 수 없다. 따라서 초기 웹 생태계에서는 이를 해결하기 위해 한 요청에 대한 response로 어떤 토큰을 돌려주고 다음 요청시에 해당 토큰을 같이 보내는 방법으로 이런 무상태성을 해결해 왔던 것이다.

예를 들어, 로그인 요청을 통해 한번 네이버에 인증이 이뤄지고 나면, 나는 네이버 내 설정 페이지도 들어갈 수 있고 여러 내가 가입한 카페에도 들어갈 수 있는 등 내 정보를 가지고 활동할 수 있는데, 인증 후 서버에서 돌려받은 정보를 가지고 매 요청에 실어 보내고 있기 때문에 서버가 이 요청을 하는 주체가 나인줄을 알고 접근 권한 등을 허용해 주는 것이다.

• 같은 도메인에서 만들어진 쿠키만 매 요청시 해당 웹 서버에 보내진다.
• 쿠키의 만료기간을 지정할 수 있다.

2. 쿠키는 어떻게 만들어지는가?

웹 서버가 HTTP 요청의 헤더에 Set-cookie를 보내면 웹 브라우저에 서버가 보낸 쿠키가 저장이 된다. 크롬의 네트워크 탭을 통해 살펴보면 다음과 같이 Response Header에 set-cookie가 있는 것을 볼 수 있다.

이 쿠키는 Application 탭에서 확인할 수 있으며, 아래와 같이 Request시에 header에 cookie에 담겨 서버에 보내지고 있는 것을 알 수 있다.

3. 쿠키를 확인해보자

다음과 같이 크롬의 경우 Application 탭에서 쿠키를 확인할 수 있다.

보면 쿠키에 Name과 Value 외에도 Domain, Path, Expires, HttpOnly, Secure, SameSite, Priority 등등 여러가지 다양한 속성들이 있는 것을 볼 수 있다. 이 속성들에 대해 살펴봄으로써 쿠키에 대해 좀 더 자세하게 알아보자.

3-1. Domain 옵션

도메인은 쿠키가 보내져야 할 도메인을 지정하는 속성이다. 디폴트로 도메인은 쿠키를 보낸 도메인으로 지정되어, 해당 호스트 이름으로 HTTP 리퀘스트가 일어날 때 보내진다. 예를 들어, google.com안에는 내가 사용하는 maps.cgoogle.com, calendar.google.com등 여러 서비스들이 존재한다.

이 때 도메인 옵션을 google.com이라고 지정해 두면 *name*.google.com 에 접속할 때 쿠키가 함께 보내진다. 브라우저는 요청이 보내질 때 호스트 네임을 비교하여 같은 도메인에 있는 쿠키를 서버에 보낸다.

도메인을 지정하지 않았을 경우, 서브도메인에서는 쿠키가 보내지지 않으나, 위의 경우처럼 도메인 옵션을 지정해두면 서브도메인에서도 쿠키가 전송된다.

3-2. Path 옵션

쿠키가 언제 보내져야 하는지 컨트롤하는 또 다른 방법은 path 옵션을 사용하는 것인데, 도메인 옵션을 확인해서 같은 도메인인지 확인하고 나면, path 옵션 비교가 일어난다. 이 때 글자 비교가 일어나는데, 예를들어, path=/blog로 지정되어 있다면, /blog, /blogminju와 같이 /blog로 시작되는 곳은 전부 쿠키가 보내질 것이다.

3-3. Expires/Max-Age 옵션

쿠키는 만료기간과 함께 생성될 수 있다. 이 때 만료기간이 있는지 없는지에 따라 세션쿠키와 영속쿠키로 나뉜다.

• 세션 쿠키는 세션이 종료될 때 사라진다. (브라우저가 닫혔을 때) 위의 예시에서 Session이라고 적혀 있는 것이 세션 쿠키이다.
• 영속쿠키는 지정된 시간이 지나면 사라지는 쿠키이다.

참고로 쿠키는 저장용량이 제한되어 있는데, 따라서 용량이 다 차게 되면 최신 쿠키를 저장하기 위해 브라우저가 알아서 기존의 쿠키들을 삭제할 것이다.

3-4. HttpOnly 옵션

HttpOnly 옵션은 Cross-site 스크립팅(XSS) 공격을 방지하기 위해 사용되는데, 이 옵션이 지정되어 있으면 자바스크립트의 Document.cookie API에 접근할 수 없고, 서버에 전송만 될 수 있다.

다음 예시와 같이 일반적으로 해당 API로 쿠키에 접근하여 쿠키를 만들고 지우는 등 여러가지를 할 수 있다.

내 이름으로 된 쿠키 만들기

document.cookie = "name=Minju; SameSite=None; Secure"
'name=Minju; SameSite=None; Secure'

3-5. Secure 옵션

secure옵션이 지정되어 있는 쿠키는 요청이 SSL이나 HTTPS 프로토콜 위에서 이뤄질 때에만 서버에 전송될 것이다. Secure 옵션이 있더라도 본질적으로 쿠키는 안전하지 않기 때문에 민감한 정보는 쿠키에 절대 저장하면 안된다.

3-6. SameSite 옵션

SameSite는 웹 어플리케이션에서 CSRF(Cross-Site Request Forgery)를 방지하기 위해 HTTP 쿠키에서 설정할 수 있는 속성이다. None, Lax, Strict 세 가지 옵션이 있는데 Cross-site인지를 확인하여 쿠키 전송 여부가 결정된다.

• None : 제한하지 않는 것으로, same-site이든 cross-site이든 쿠키 전송이 가능하다.
• Lax : 기본적으로 same-site일 때 쿠키가 전송되며, cross-site일 경우 top level navigation이 변경되거나 '안전한' Http 메소드가 사용될 때에만 쿠키가 전송된다.
• Strict : same-site일 경우에만 쿠키가 전송된다.

2020년 기준으로 default 값이 None 에서 Lax로 변경이 되었다. Lax일 경우 내가 다른 사이트에서 링크를 통해 쿠팡에 들어갔을 때, 내가 검색했던 키워드가 있는 쿠키값이 쿠팡에 전송되어, 쿠팡이 나에게 맞춤 컨텐츠를 보내줄 수 있게 하는 등의 역할을 한다. 만약 Strict로 되어 있다면 쿠팡에 쿠키가 전송되지 않아 맞춤 광고를 보지 못했을 것이다.

예시를 통해 옵션들에 대해 더 알아보자.

내가 접속한 사이트를 https://minju.com이라고 했을 때, lax, strict에 대해 아래 예시들은 어떻게 동작할까?

 

case 1.<img src="https://ariel.com/1.png" />

minju.com에서 이미지 태그를 통해 ariel.com의 이미지 하나를 가져왔다. same-site가 아니기 때문에 Lax와 Strict모두 쿠키가 전송되지 않는다.

 

case 2. <a href="https://ariel.com/blog/samesite.html">Link</a>

링크를 통해 다른 사이트에 이동하는 것인데, 최상위 navigation에 변동이 일어나므로, Lax에서는 쿠키가 전송되지만, strict에서는 쿠키가 전송되지 않는다.

 

case 3. <iframe id="if" src="/hello"></iframe>
<iframe id="if" src="/hello"></iframe>
<script> document.getElementById("if").contentDocument.location.href="https://ariel.com"
iframe 내부에서 ariel.com으로 이동하게 될 텐데, top-level navigation이 아니기 대문에 Lax와 Strict모두에서 쿠키가 전송되지 않는다.

 

case 4.document.location.href="https://ariel.com"</script>

최상단에서 navigation 변동이기 때문에 Lax일 때는 쿠키전송, Strict일 때는 쿠키전송이 일어나지 않는다.

 

Same-site 옵션을 보다보면, 두 가지 질문이 생긴다.

첫 번째, CSRF란 무엇일까?

사이트 간 요청 위조의 줄임말로, 인증된 사용자가 웹 어플리케이션에 특정 요청을 보내도록 유도하는 공격 행위를 말한다. 예를 들어 내가 A라는 웹사이트에 로그인 되어있는 상태에서 피싱 사이트를 클릭했을 때, 해당 URL을 클릭함과 동시에 A라는 웹사이트에서 받아온 내 정보를 가지고 A웹사이트에 내 비밀번호를 변경해달라고 하는 요청, 혹은 돈을 송금해달라고 하는 요청들을 하도록 하는 것이다.

 

**비교, XSS란?
Cross Site Scripting 의 줄임말로, 공격자가 클라이언트 측 스크립트를 웹 사이트에 삽입하여 다른 사용자의 브라우저에서 수행되게 하는 공격의 유형`을 말한다. 삽입된 코드는 피해 사용자의 사이트 권한 쿠키를 공격자에게 보내는 종류의 악성작업을 수행할 수 있고, 공격자는 전달받은 정보를 활용해 마치 피해 사용자인 것처럼 위장하여 사이트에 로그인하고 피해 사용자가 할 수 있는 모든 작업을 수행할 수 있다.

Cross-site 기준은 어떻게 될까?

HTTP 목적지의 사이트와 현재 주소 표시창에 있는 사이트 간에 비교가 일어나는데, Same-site인지 판별할 때에는 모든 도메인을 확인하지 않고, .com/.net/.org같은 public suffix의 앞에 있는 도메인까지만 비교를 하게 된다. (Same Origin인지 확인할 때에는, scheme(http)와, Host, Port 모두를 확인하여 이 셋 중에 하나라도 다르면 다른 Origin이라고 판별한다.)

 

public-suffix의 의미를 좀 더 짚고 가야하는데, public suffix는 바로 그 앞에있는 도메인을 유저들이 만들 수 있어야 한다. publicsuffix.org 라는 곳에서 이걸 관리하는데 예를 들어 이 사이트에 보면 github.io자체가 public suffix로 등록되어 있다. 따라서 same-site를 판별할 때, minju.github.io 까지 비교할 것이다.

 

예시를 한번 보도록 하자.

1) https://www.minju-k.com/path.page.html
2) https://blog.minju-k.com:8443/sop.html
3) http://www.minju-k.com/index.html
4) https://minju.github.io/index.html
5) https://hello.github.io/index.html

위 예시에서, 1,2,3은 Same-site라고 볼 수 있고, 4,5번 같은 경우에는 github.io 자체가 public suffix이기 때문에 바로 앞단계의 도메인이 달라 cross-site라고 볼 수 있다.

세션이란?

쿠키에 대해 살펴봤으니, 세션에 대해 살펴보도록 하자.

 

세션과 쿠키의 가장 큰 차이점은 정보를 관리하는 위치인데, 쿠키의 경우 사용자의 정보가 브라우저에 저장되어 있다가 서버에게 보내진다고 한다면, 세션의 경우 세션 ID만 쿠키에 전달해주고, 정보는 세션 DB에서 관리한다. 각 클라이언트에게 고유 ID를 부여하여, 세션 ID로 클라이언트를 구분해서 요구에 맞는 서비스를 제공해 주는 방식으로, 보안 면에서 쿠키보다 우수하다.

 

세션은 서버에서 관리하고 있기 때문에, 서버 측에서 강제 탈퇴, 넷플릭스 계정 4명까지 제한 등 여러가지 일을 할 수 있지만, 서버의 메모리를 사용하기 때문에 사용자가 많아질 경우 속도가 느려질 수 있고 메모리가 감당하지 못하는 경우가 있을 수 있다. 매 요청마다 클라이언트가 쿠키롤 통해 보내온 세션 ID를 세션 DB를 통해 확인해야 하기 때문이다.

 

간단하게 토큰과 비교하자면, 토큰은 서버의 비밀 키로 사인을 해 준 종이를 돌려주는 것과 같은데, 사용자는 서버에서 발급한 토큰을 다시 서버에 전송할 때, 만약 서버가 전달해 준 토큰이 아니라면 인증이 어려운 원리를 사용하는 것이다. 세션의 경우에는 서버가 로그인된 유저의 모든 정보를 저장하기 때문에 사용자가 이미 접속해 있음을 알아차릴 수 있는 반면, 토큰의 경우에는 인증된 종이(토큰)만 내밀면 되기 때문에 여러 사용자가 같은 토큰으로 로그인을 할 수도 있다.

 

 

*참고

https://web.dev/i18n/ko/samesite-cookies-explained/
https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies
https://www.youtube.com/watch?v=tosLBcAX1vk&t=417s
https://www.youtube.com/watch?v=Q3YuKipzPbs&t=811s