[HTTP] Cookie 와 Session

쿠키 (Cookie)

서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각으로, key=value 형식의 문자열 데이터 묶음이다.

클라이언트가 문자열 데이터 조각들을 저장해놓았다가 동일한 서버에 재 요청시 쿠키 데이터를 전송할 수 있다.

쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 시에 Request Header를 넣어서 자동으로 서버에 전송한다.

• 도메인 단위로 저장
• 표준안 기준, 사이트당 최대 20 개 및 4KB로 제한
• 영구 저장 불가능

 

📌 HTTP 쿠키 헤더

1. Cookie 요청 헤더

HTTP 요청 시 클라이언트에서 서버로 전달하는 쿠키 헤더
서버의 세션 상태를 담은 SessionID 혹은 각종 클라이언트 정보들을 담고 있다.

2. Set-Cookie 응답 헤더

서버에서 클라이언트로 전달하는 쿠키 헤더
클라이언트는 이 정보를 바탕으로 쿠키를 만들어 브라우저에 저장

3. 쿠키 저장

쿠키는 key=value 형태로 저장되는 문자열로서 여러개의 데이터를 콤마(,)로 열거하여 저장해 구분한다.
쿠키는 유효 기간이나 도메인 등을 설정한 파라미터들을 세미콜론(;)을 통해 열거한다.

 

📌 쿠키 파라미터

NAME=VALUE	쿠키에 부여된 이름과 값 (필수)
Domain=도메인명	쿠키 적용 대상이 되는 도메인 명
Path=PATH	쿠키 적용 대상이 되는 경로
Expires=DATE	쿠키 만료 날짜(국제 표준시 UTC Date)
max-age=TIME	쿠키  만료 타이머(s) 설정
Secure	HTTPS로 통신하는 경우에만 쿠키를 송신
HttpOnly	쿠키를 자바스크립트에서 액세스 하지 못하도록 제한
SameSite	크로스 사이트(Cross-site)로 전송하는 요청의 경우 서드 파티 쿠키의 전송에 제한

 

1️⃣ NAME=VALUE

// Name이 user고, Value가 John인 쿠키 추가
document.cookie = "user=John"

 

• Name과 Value 속성은 데이터를 저장하고 읽는 데 사용하는 속성이다.
• 따라서 쿠키를 사용할 때는 Name과 Value 속성을 반드시 지정해야 한다.

2️⃣ Domain

// naver.com, www.naver.com, blog.naver.com, cafe.naver.com 서브 도메인도 모두 포함
document.cookie = "user=John; Domain=.naver.com"

• Domain 속성을 입력하지 않으면 현재 도메인의 경로로 자동 입력된다.
• 쿠키에 도메인을 설정하면, 해당 도메인 페이지에서만 쿠키 사용 접근이 가능하다.
• 해당 도메인의 서브 도메인까지 모두 포함한다.
  domain=example.org 지정
  .example.org 형태로 저장 (도메인 앞에 점은 서브 도메인도 허용하겠다는 뜻이다)
  example.org → 쿠키 접근 가능
  http://www.example.org → 쿠키 접근 가능
• 만일 현재 도메인에서 설정한 쿠키를 퍼스트 파티 쿠키(First-party cokkies) 라 하고, 다른 도메인으로 설정된 쿠키를 서드 파티 쿠키(Third-party cokkies)라 한다.
  

3️⃣ Path

document.cookie = "user=John; path=/"

• Path 속성을 입력하지 않으면 현재 도메인의 경로로 자동 입력된다.
• 쿠키에 경로를 설정하면, 해당 페이지 경로에서만 쿠키 사용 접근이 가능하다.
• 해당 경로의 하위 경로까지 모두 포함한다. 그래서 루트 경로(/) 로 설정하면 모든 경로에 쿠키가 유효하다는 뜻이 된다.
  path=/home 지정 
  /home/level1 → 접근 가능 
  /home/level1/level2 → 접근 가능 
  /hello → 접근불가능 (다른 경로)
  
• Path 속성을 ' / '로 설정하면 도메인 내의 모든 곳에서 접근할 수 있다. (쿠키의 범위를 좁게 잡을 수록 보안에는 좋다.)

4️⃣ Expires

document.cookie = `b=2; expires=${new Date(2024, 05, 25).toUTCString()}`
document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT"

• Expires 속성은 쿠키의 파기 날짜를 지정하는 속성이다.
• Expires 속성에는 GMT 형식이나 UTC 형식으로 날짜를 입력해야 한다.
• 만료 날짜나 시간을 설정하지 않으면, Expire 에 '세션' 이라고 세팅되며 브라우저가 종료될 때 쿠키가 삭제된다.
  👉 쿠키는 만료 날짜나 시간을 같이 명시해줘야한다.

5️⃣ Max-age

// 1시간 뒤에 쿠키가 삭제됩니다.
document.cookie = "user=John; max-age=3600";

// 만료 기간을 0으로 지정하여 쿠키를 바로 삭제함
document.cookie = "user=John; max-age=0";

• expires 옵션의 대안으로, 쿠키 만료 기간을 설정할 수 있게 해준다.
• 현재부터 설정하고자 하는 만료일시까지의 시간을 초로 환산한 값을 설정한다.

6️⃣ Secure

document.cookie = "user=John; Secure"

Secure 속성을 지정하면 해당 쿠키는 HTTPS 를 사용해서만 요청할 수 있다.

7️⃣ HttpOnly

document.cookie = "user=John; httpOnly"

• 설정 시 자바스크립트에서 쿠키에 접근할 수 없다.
• 자바스크립트로 쿠키를 탈취할수 없어, XSS 공격을 방지할 수 있다. 👉 쿠키 조작을 방지하기 위해 설정하는 것이 좋다. 

 

8️⃣ SameSite

• SameSite 속성은 서드 파티 쿠키의 보안적 문제를 해결하기 위해 만들어진 기술이다.
• XSRF, CSRF 공격을 방지할 수 있다.
• 요청 도메인과 쿠키 정보 내의 도메인이 다른 크로스 사이트(Cross-site)로 전송하는 요청에 대해서 제한을 둘 수 있다.

✔ SameSite 옵션

1. Strict: 반드시 같은 도메인에서만 사용 가능 (하위 도메인 포함)
2. Lax: 같은 도메인에서만 사용 가능하지만, 유저가 링크를 클릭해서 접속하거나 하는 경우에는 다른 도메인에서도 사용 가능 (기본 값)
3. None: 다른 도메인에서도 사용 가능. Secure 옵션과 함께 사용해야 함

 

예시1 ) SameSite=Strict를 사용하고 같은 도메인인 경우
예를들어서 codeit.kr이라는 사이트에서 api.codeit.kr이라는 백엔드 서버로 리퀘스트를 보내는 상황을 생각해 봅시다.
백엔드 서버에서는 리스폰스로 SameSite=Strict와 Domain=codeit.kr이라는 옵션으로 쿠키를 설정하려고 합니다.

1. codeit.kr이라는 사이트에서 사용자가 api.codeit.kr라는 백엔드 서버로 리퀘스트를 보냅니다.
2. 백엔드 서버는 리스폰스로 Set-Cookie 헤더를 보내는데, SameSite=Strict와 Domain=codeit.kr이라는 옵션으로 쿠키를 설정해서 보내줍니다.
3. 웹 브라우저는 리퀘스트를 보냈던 주소(api.codeit.kr)의 도메인과 쿠키에 적혀있는 도메인(codeit.kr)이 일치하는지 확인합니다. 일치한다고 판단하면, SameSite=Strict 조건을 만족하기 때문에 쿠키를 저장합니다.

예시2 ) SameSite=Strict를 사용하지만 다른 도메인인 경우
반대로 만약 codeit.kr 이라는 사이트에서 api.example.com라는 백엔드 서버로 리퀘스트를 보내는 상황을 생각해 봅시다. 백엔드 서버에서는 리스폰스로 SameSite=Strict와 Domain=example.com 이라는 옵션으로 쿠키를 설정하려고 합니다.

1. codeit.kr이라는 사이트에서 사용자가 api.example.com이라는 백엔드 서버로 리퀘스트를 보냅니다.
2. 백엔드 서버는 리스폰스로 Set-Cookie 헤더를 보내는데, SameSite=Strict와 Domain=example.com이라는 옵션으로 쿠키를 설정해서 보내줍니다.
3. 웹 브라우저는 리퀘스트를 보냈던 주소(api.example.com)의 도메인과 쿠키에 적혀있는 도메인(example.com)이 일치하는지 확인합니다. 이 경우에는 도메인은 일치하지만 SameSite=Strict 조건을 만족하지 않는데요. 리퀘스트를 보낸 사이트의 도메인이 codeit.kr이기 때문에 그렇습니다. 그래서 쿠키를 저장하지 않습니다.

예시3 ) SameSite=None을 사용하고 다른 도메인인 경우
반대로 만약 codeit.kr 이라는 사이트에서 api.example.com라는 백엔드 서버로 리퀘스트를 보내는 상황을 생각해 봅시다.
백엔드 서버에서는 리스폰스로 SameSite=None과 Domain=example.com 이라는 옵션으로 쿠키를 설정하려고 합니다.

1. codeit.kr이라는 사이트에서 사용자가 api.example.com이라는 백엔드 서버로 리퀘스트를 보냅니다.
2. 백엔드 서버는 리스폰스로 Set-Cookie 헤더를 보내는데, SameSite=None과 Domain=example.com이라는 옵션으로 쿠키를 설정해서 보내줍니다.
3. 웹 브라우저는 리퀘스트를 보냈던 주소(api.example.com)의 도메인과 쿠키에 적혀있는 도메인(example.com)이 일치하는지 확인합니다. 이 경우에는 리퀘스트를 보내는 쪽의 도메인(codeit.kr)과 받는 쪽의 도메인(example.com)이 일치하지 않지만 SameSite=None 옵션 덕분에 쿠키를 저장하게 됩니다.

세션 ( Session )

브라우저로 웹서버에 접속한 시점부터 브라우저를 종료하여 연결을 끝내는 시점까지의 일련의 요청을 하나의 상태로 간주하고, 그 상태를 일정하게 유지하는 기술이다.
쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리합니다. 

• 도메인 단위로 저장
• 5MB 제한
• 세션 혹은 영구 저장 가능

👉 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.

• 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지합니다.
• 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능 합니다.
• 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 됩니다.
• 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 됩니다.
• 클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는 데 이것이 세션 ID입니다.

 

쿠키 vs 세션 

	쿠키	세션
저장위치	클라이언트	웹 서버
소멸 시기	쿠키 저장시 만료기간 설정	브라우저 종료시 (지정 가능)
저장타입	파일	객체
속도	빠름	느림
보안	낮음	높음
저장정보	지워져도 되고, 조작되거나 가로채도 되는 정보	사용자나 다른 사람에게 노출되면 안되는 중요한 정보

• 가장 큰 차이점은 사용자의 정보가 저장되는 위치입니다. 때문에 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용합니다.
• 보안 면에서 세션이 더 우수하며, 요청 속도는 쿠키가 세션보다 더 빠릅니다. 그 이유는 세션은 서버의 처리가 필요하기 때문입니다.
• 보안, 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 sessionid 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안성이 좋습니다.
• 라이프 사이클, 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다. 또한 만료기간을 넉넉하게 잡아두면 쿠키삭제를 할 때 까지 유지될 수도 있습니다.
• 반면에 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제됩니다. 예를 들어, 크롬에서 다른 탭을 사용해도 세션을 공유됩니다. 다른 브라우저를 사용하게 되면 다른 세션을 사용할 수 있습니다.
• 속도, 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 가집니다.

쿠키와 세션을 통한 인증/인가 절차

 

1. 클라이언트가 로그인 하면 서버는 회원정보를 대조하여 인증한다. (인증)

2. 회원(클라이언트) 정보를 세션 저장소(서버에 있음)에 생성하고 session ID를 발급한다. 

3. http response header 쿠키 부분에 발급한 session ID를 담아서 보낸다.

4. 클라이언트에서는 session ID를 쿠키 저장소에 저장하고 이후에 http 요청을 보낼 때마다 쿠키에 session ID를 담아서 보낸다.

5. 서버에서 쿠키에 담겨 온 session ID에 해당하는 회원 정보를 세션 저장소에서 가져온다. (인가)

6. 회원 정보를 바탕으로 처리된 데이터를 응답 메시지에 담아서 클라이언트에 보낸다.

쿠키와 세션을 이용한 세션 기반 인증 방식의 문제점

1. 다른 악의를 가진 사용자가 session ID 탈취 가능 -> 보안에 취약  

2. http 의 가장 큰 특성 중 하나인 stateless를 위배한다. stateless는 서버가 클라이언트의 상태를 저장하지 않아야 하지만 세션 저장소에 클라이언트의 상태를 저장하게 되므로 stateful 하게 된다.

 

해결법 : https 사용, 세션 클러스터링, 스티키 세션, 토큰 기반 인증 방식(jwt)

 

참고

🌐 웹 브라우저의 Cookie 헤더 다루기 (tistory.com)

쿠키의 SameSite 옵션이란? | 코드잇 (codeit.kr)

쿠키와 세션 개념 (tistory.com)

[Web] 쿠키와 세션의 차이점, 인증과 인가, 세션 기반 인증 방식 — 결국은 되게 하기 (tistory.com)