쿠키란?

Gon Kim·2022년 9월 18일
web쿠키
0

이왕 공부한 김에 아까워서 하는 정리[0년차]

목록 보기
1/14

MDN에 따르면 쿠키는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각이다.

*조금 찾아보고 나서 되돌아보니, 그냥 한번 요청 보낼 때 필요한 데이터들을 미리 저장해뒀다가 함께 동봉해서 보내는 것이더라

1. 어떤 문제/이유로 등장했을까?

위키백과 - 쿠키 등장 배경
매직 쿠키는 루 몬툴리가 1994년 6월 웹 통신에서 이것들을 사용하겠다는 생각을 했을 때 컴퓨팅에 이미 사용되고 있었다. 당시 그는 넷스케이프 커뮤니케이션스의 직원이었으며 MCI를 위한 전자 상거래 애플리케이션을 개발하고 있었다. 빈트 서프와 존 클렌신은 넷스케이프 커뮤니케이션스와의 기술 토론에서 MCI를 제시했다. MCI는 서버가 부분적인 트랜잭션 상태를 보유하는 것을 원치 않았으나 이러한 이유로 이들은 넷스케이프에게 각 사용자의 컴퓨터의 상태를 저장하는 방법을 강구할 것을 대신 요청하였다. 쿠키는 가상 쇼핑 카트를 신뢰성있게 구현할 때의 문제의 해결책을 제공하였다.

W3에서 사용하는 http는 stateless한 프로토콜이다. 요청-응답이 끝났을 때 상태 정보를 유지하지 않는 것이다. 따라서 다른 URL로 접속하는 등 또 다른 요청-응답 과정이 일어날 때, 이 전에 다뤘던 사용자에 대한 정보는 모두 사라진 이후이다.

먼 옛날 W3가 단순히 데이터의 교환으로만 쓰였을 때는 위와 같은 http의 특징이 문제가 되지 않았을지도 모른다(물론 진짜 문제가 없었을지는 나도 모른다!)

하지만 W3와 인터넷을 기반으로 다양한 서비스들이 발생하며, 사용자의 무언가를 추적해야한다거나, 혹은 사용자의 정보를 기억해두면 좋겠다 싶은 필요성이 느껴졌고, 쿠키가 등장했다.

2. 어떻게 해결했을까?

클라이언트에 쿠키를 저장하고, 서버에 요청할 때 함께 동봉해 보내주는 방식

  • 서버 쪽에서는 클라이언트가 어떤 친구인지 알 도리가 없기에, 일종의 증명서를 발급한다. 증명서라고 해봤자 그냥 텍스트이다.
  • 서버는 이를 브라우저에게 보내고, 브라우저는 이들을 저장해 놓았다가, 해당 쿠키를 발급한 서버에 재 요청시, 이 텍스트 조각을 함께 전송한다. 매 요청이 별개인 http에서, 이전 상태를 포함해 보내는 방식인 것이다.
  • 서버는 이 쿠키를 기반으로 다양한 동작을 수행해 이 친구의 상태를 파악한다.

3. 사용 용도

MDN에서 말하는 주 사용처는 다음과 같다.

  • 세션 관리
    • 서버에 저장해야할 로그인, 장바구니, 게임 스코어 등의 정보 관리
  • 개인화
    • 사용자 선호, 테마 등의 세팅
  • 트래킹
    • 사용자 행동을 기록, 분석하는 용도

**쿠키는 요청을 보낼 때마다 함께 보내져서, 클라이언트 측에 저장할 정보라고 쿠키를 무작정 쓰면 성능 저하의 원인이 된다고 한다. 웹 스토리지/indexed DB를 사용하길 권장한다. → 얘들은 다른 글에서 다루도록 할 것이다!

4. 사용 방법

헤더

헤더를 통해 쿠키를 설정할 수 있다.

HTTP 응답 헤더 중 Set-Cookie를 이용한다. 클라이언트에서 다시 요청시 Cookie 헤더를 사용한다.

응답 예시

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

쿠키를 받은 후, 보내는 요청 예시

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

헤더 속성

크롬 개발자 도구에 들어가보니 쿠키 부분에 이러한 column들이 있었다.

이름/값/도메인/path/expires/max-age/크기/httponly/secure/same-site/same-party/partition key/priority

이름과 값은 key-value의 key, value이다. 그 외 대부분읜 mdn에서 가르쳐준다!(짱이다)

라이프 타임 설정

일반적으로 Expires, Max-Age 속성을 사용한다. Expires 속성에 명시된 날짜에 삭제되거나, Max-Age에 명시된 기간 후에 삭제된다. Expires 속성에 명시된 날짜는 클라이언트 기준이다. 서버기준이 아니다!

라이프 타임 설정 예시

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Secure/HttpOnly

Secure은 보안을 위해 HTTPS를 사용할 때만 전송하도록 하는 속성이다. 그러나 본질적으로 안전한건 아니라서 정말 민감한 정보는 쿠키에 저장하지 말라고 한다.

HttpOnly는 XSS를 방지하기 위한 속성으로, js의 api로 접근할 수 없고, 오로지 해당 쿠키 데이터가 전송만 될 수 있도록 한다고 한다.

예시

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

  • HttpOnly 속성이 없어서 document.cookie로 접근이 되는 developer.mozilla.org의 쿠키들

쿠키의 스코프

Domain과 Path는 스코프를 정의한다. 어떤 URL에 쿠키를 보내야 하는지와 관련된 것이다. A라는 웹사이트에서 받은 쿠키를 굳이 B, C와 같은 다른 웹사이트에서 쓸 일이 없지 않은가?

Domain은 쿠키가 전송되게할 호스트를 명시하며, 없는 경우 현재 문서의 호스트 일부를 기본 값으로 지정한다. 도메인이 명시되면 서브 도메인들은 항상 포함된다고 한다.

  • Domain=mozilla.org인 경우 쿠키들은 devloper.mozilla.org와 같은 서브 도메인 에도 포함되는 것이다.

Path는 Cookie 헤더를 전송하기 위해 URL 내에 반드시 존재해야하는 URL 경로를 지정하는 속성이다.

  • Path=/docs가 설정되면 /docs, /docs/Web/, /docs/Web/HTTP 따위의 경로들이 모두 매치되는 것이다.

💡 서브도메인
[A subdomain is an optional part of an internet domain name that appears before the root domain and TLD
. A common subdomain is 'www' and often simply a specific directory on the server. Subdomains are commonly used to separate distinct functions of a website, such as a blog, shop, or member's only area] 간단히 말해 root 도메인에서 확장시켜나간 도메인. 보통 prefix를 붙인다.

💡 First-party/Third-party
www.example.com에 접속한 상태라고 가정해보자. 해당 웹페이지의 구석에서 'img src=”www.image.com/image.jpeg”' 따위의 태그를 통해 이미지를 가져오고 있다고 하자. 이 때 사용자가 www.image.com에 관련된 쿠키를 가지고 있다면, 해당 쿠키가 www.image.com의 서버로 전송되는데, 이를 third party 쿠키라고 한다. 사용자가 접속해있는 페이지와 다른 도메인을 갖는 쿠키가 존재할 수 있는 것이다. 반대로 사용자가 접속해있는 웹사이트의 도메인과 같은 도메인을 갖는 쿠키는 first-party인 것이다. 즉, 사용자가 어떤 웹사이트에 접속해있냐에 따라서 같은 쿠키고 first-party가 되기도 하고, third-party가 된다.

Same-site

Cross-site로 전송하는 요청에서 발생하는 쿠키와 관련된 문제를 방지하기 위한 것이다. Cross-site이 뭘까? site을 넘나드는? 와닿지 않는다. CSRF를 살펴보면 더 감이 올 것이다.

💡 CSRF(Cross Site Request Forgery)
쿠키를 이용해 사용자 인증을 진행하는 웹사이트가 대상이 될 수 있는 공격 방법이다.

  • 유저는 공격 대상이 되는 사이트에 쿠키를 이용해 사이트 인증을 한다.
  • 유저는 인증을 했으므로, 브라우저에는 쿠키가 있는 상태이다.
  • 공격자는 피해자에게 공격 대상과는 당연히 다른 도메인인, 사이트 링크를 누르게 한다.
  • 링크를 눌러 받게 되는 HTML 문서에는, 공격 대상 사이트에 HTTP 요청을 보내는 부분들이 존재한다.
  • 이 요청은 공격 대상이 되는 사이트에 관한 쿠키를 thrid party 쿠키로 사용하게 되므로, 유저의 사용자 인증 관련 쿠키가 멋대로 사용되게 된다.

Same-Site는 third party로서 전송되는 쿠키에 제한 사항을 두는 속성이다.

  • None
    • SameSite가 적용되지 않은 상태. Third party 쿠키도 항상 전송된다.
  • Strict
    • Third party 쿠키는 전혀 전송되지 않고, first-party 쿠키만 전송된다.
  • Lax
    • 보통은 Third party 쿠키가 전송되지 않지만 아래와 같은 몇가지 예외적인 상황이 존재한다.
    • Top Level Navigation인 경우
      • (O) - 유저가 a 태그를 클릭하거나, window.location.replace 등오로 인해 자동으로 이루어지는 이동, 302 status code에 의해 자동으로 이루어지는 redirect의 경우
      • (X) - img, iframe 태그에 삽입되어 보내지는 http 요청. navagation이 아니거나, top level이 아니므로 전송되지 않는다.
    • 안전한 http 메서드의 경우
      • “안전한”이란 서버의 상태를 바꾸지 않을 것이라고 기대되는 것이라고 한다. ex) (O) - GET / (X) - POST, DELETE

Partition key

https://developer.chrome.com/docs/privacy-sandbox/chips/ 추가 예정

그 외

저장 위치

브라우저마다 다르며, 내가 사용하는 맥북 기준 크롬의 쿠키는
/Users/{username}/Library/Application Support/Google/Chrome/Default에 Cookies라는 이름으로 저장된다. 열어보니 바이너리 파일인 것 같더라

참고 자료

[쿠키란? 쿠키의 등장 배경][https://newprogrammatic.com/blog/what-are-browser-cookies-in-digital-advertising/](https://newprogrammatic.com/blog/what-are-browser-cookies-in-digital-advertising/)

[브라우저 쿠키와 sameSite][https://seob.dev/posts/브라우저-쿠키와-SameSite-속성/](https://seob.dev/posts/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EC%BF%A0%ED%82%A4%EC%99%80-SameSite-%EC%86%8D%EC%84%B1/)

[MDN 쿠키][https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies](https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies)

[MDN same-site][https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite)

[javascript.info]https://ko.javascript.info/cookie#ref-1231

profile
Gon Kim
응애
다음 포스트

함수형 프로그래밍

0개의 댓글