🍪 쿠키란? (What is Cookie?)

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

A cookie (also known as a web cookie or browser cookie) is a small piece of data a server sends to a user's web browser. The browser may store cookies, create new cookies, modify existing ones, and send them back to the same server with later requests. Cookies enable web applications to store limited amounts of data and remember state information; by default the HTTP protocol is stateless.

• 쿠키는 데이터의 작은 조각이다
  • 서버가 웹 브라우저에게 보내는
  • 브라우저는 쿠키를 저장하거나, 생성하거나, 존재하는 쿠키를 수정할 수도 있고
  • 서버에게 이후 요청에 담아 보낼 수도 있다
• 쿠키는 web application이 한정된 양의 데이터를 저장할 수 있게 하고
  • 상태 정보를 기억하도록 한다(HTTP protocol → 무상태성 프로토콜 → 상태정보를 기억시켜준다!)

🍪 쿠키는 어디에 쓰이는가 (What c🍪🍪kies are used for)

to determine whether different requests come from the same browser/user

다양한 요청이 동일 브라우저/사용자부터 오는지 결정

then issue a personalized or generic response as appropriate

적절히 개인화/일반화된 응답을 반환함

💡 Sign-in System
1. 사용자가 로그인 폼을 제출하여 sign-in 자격 증명을 보낸다
2. 자격 증명이 옳다면 → 서버는 UI를 업데이트 한다 → 사용자가 로그인했음을 나타내기 위해
3. 그리고 로그인 상태를 브라우저에 기록하는 세션 아이디를 포함한 쿠키를 응답한다
4. 이후, 사용자가 같은 사이트 내 다른 페이지로 이동 시, 브라우저는 사용자가 로그인했다는 걸 나타내는 요청에 상응하는 세션 아이디를 포함한 쿠키를 보낸다
5. 서버가 세션 아이디를 체크하고 그게 여전히 유효하다면 → 유저에게 개인화된 새로운 페이지를 보낸다.
--> 만약 유효하지 않다면, 세션 아이디는 삭제되고, 사용자는 페이지의 generic version을 보게 된다(아니면 뭐 권한 없음이 뜨거나.. 로그인 다시 하라 뜨거나)

🍪 쿠키의 세 가지 목적(주요 사용 목적)

1. 세션 관리(Session Management)
   • 서버에 저장해야 할 로그인/장바구니/게임 스토어 등 정보 관리
2. 개인화(Personalization)
   • 사용자가 선호하는 테마 등 세팅
3. 트래킹(Tracking)
   • 사용자의 행동 기록, 분석하는 용도

💽 데이터 저장

In the early days of the web when there was no other option, cookies were used for general client-side data storage purposes. Modern storage APIs are now recommended, for example the Web Storage API (localStorage and sessionStorage) and IndexedDB.

• 웹 초창기.. 다른 선택지가 없던 시절
  • 쿠키는 클라이언트 사이드의 데이터 저장 목적으로 쓰였다
• 그러나 현재는 Modern storage API 사용
  • localStorage, sessionStorage
  • 그리고 IndexDB

→ 이들은 모두 저장을 염두에 두고 설계 되었으며, 서버에 데이터를 절대 보내지 않는다

그리고, 저장을 위해 쿠키를 사용하는 데 따른 단점도 없다!

🍪 쿠키를 만들고, 업데이트하고, 삭제하기

• HTTP 요청을 받고 나면 서버는 → 하나 혹은 그 이상의 Set-Cookie 헤더를 포함한 응답을 보낸다

Set-Cookie: <cookie-name>=<cookie-value>

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

[page content]

🍪 쿠키의 생명주기를 결정하기

Set-Cookie 헤더로 쿠키가 생성되는 시점에 쿠키가 삭제되어야 하거나 하는 쿠키의 생명 주기를 세팅할 수 있다

• 영구 쿠키는 Expires 속성으로 삭제 시점을 세팅할 수 있다

  Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;

  • 혹은 Max-Age 속성으로 주기를 세팅할 수 있다

    Set-Cookie: id=a3fWa; Max-Age=2592000

• 세션 쿠키 → Max-Age or Expires 속성이 없는 쿠키

  • 현재 세션이 끝나면 삭제된다

  • 브라우저는 현재 세션의 끝을 결정함

  • 몇몇 브라우저는 재시작시 저장해둔 세션을 쓰기도 한다
    - 세션 쿠키가 무한으로 지속되도록 할 수도 있다

    There are some techniques designed to recreate cookies after they're deleted. These are known as "zombie" cookies. These techniques violate the principles of user privacy and control, may violate data privacy regulations, and could expose a website using them to legal liability.

  • 좀비 쿠키라고 알려져 있음

    • 사용자 privacy, control을 위반함
    • 데이터 privacy 규정을 위반할 수도 있다 → 법적 책임에 노출될 수도 있다

💡 세션 쿠키 사용은 지양하도록 하자..!

🍪 쿠키 값을 업데이트하기

HTTP를 통해 쿠키를 업데이트할 때, 서버는 Set-Cookie 헤더를 보냄으로써(현재 쿠키와 동일한 name, 다른 value) 업데이트 가능하다

Set-Cookie: id=new-value

🍪 보안 이슈

쿠키에 정보를 저장할 때, 쿠키 내 모든 값이 보인다면?

end user에 의해 변경이 가능하다면?

으악 싫어!!

→ 세션 ID를 훔쳐서 로그인한 것처럼 할 수도 있고.. 여러 정보 탈취 등 범죄까지도 가능할 것

💡 쿠키를 보호해야겠다.. 그럼 방법에는 뭐가 있냐 하면

🍪 쿠키의 접근을 막기

You can ensure that cookies are sent securely and aren't accessed by unintended parties or scripts in one of two ways: with the Secure attribute and the HttpOnly attribute:

• Secure 속성이나 HttpOnly 속성을 이용하면 쿠키를 안전하게 보호할 수 있다..오호!

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

Secure attribute

• 암호화된 요청을 서버로 보내게 됨
  • HTTPS 프로토콜
• localhost를 제외한 비보호된 HTTP 프로토콜로는 절대 보내지지 않는다!
• 즉, man-in-the-middle 공격자들은 쉽게 접근할 수 없다는 것
• 그러나 쿠키 내 민감한 정보에 모든 접근을 막는다고는 할 수 없다
  • 예를 들면 클라이언트의 HDD에 접근 가능한 누군가(HttpOnly가 세팅되지 않은 경우)는 정보를 읽고 수정할 수 있다.

HttpOnly attribute

• JavaScript에 의해 수정될 수 없다 → Document.cookie 등으로 인해 수정이 안 됨
  
• 서버에 닿았을 때만 수정이 됨
• XSS(cross-site scripting) 공격 예방에 도움이 됨

🍪 쿠키가 전송되는 위치

• Domain, Path 속성은 쿠키의 범위(scope)를 정의한다
  • 쿠키가 어느 URL로 보내져야 하는지

Domain attribute

• 서버가 어느 곳에서 쿠키를 받아야할지 정의함
• 쿠키는 이 subdomain과 특정된 서버에서 이용 가능해진다

💡 이렇게 Domain 속성을 정하면, 제한하는 거 아닌가?…

If the Set-Cookie header does not specify a Domain attribute, the cookies are available on the server that sets it but not on its subdomains. Therefore, specifying Domain is less restrictive than omitting it. Note that a server can only set the Domain attribute to its own domain or a parent domain, not to a subdomain or some other domain. So, for example, a server with domain foo.example.com could set the attribute to example.com or foo.example.com, but not bar.foo.example.com or elsewhere.com (the cookies would still be sent to subdomains such as bar.foo.example.com though). See Invalid domains for more details.

• 도메인을 세팅해주지 않는다면 → 서버에서는 이용 가능하나, 서브 도메인에서는 이용 가능하지 않다

💡 그러므로, 도메인을 명시해주는 것이 해주지 않는 것보다 덜 제한적이다!

Path attribute

• 쿠키 헤더를 보내기 위해 요청된 URL에 반드시 존재해야하는 URL 경로를 지정해줌

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Path=/docs

“/” → directory separator

접근 가능한 URL들 예시 (Path=/docs 인 경우)

• /docs
• /docs/
• /docs/Web/
• /docs/Web/HTTP

접근 불가능한 URL들 예시

• /
• /docsets
• /fr/docs

🍪 SameSite 로 써드 파티 쿠키 제어하기

• SameSite 속성은 서드 파티 쿠키를 제어하기 위해 사용된다.
  • Strict: 쿠키가 동일한 사이트에서만 전송된다.
  • Lax: 탭 이동과 같은 간단한 네비게이션 요청에도 쿠키가 전송된다.
  • None: 서드 파티 요청에도 쿠키가 전송되지만, 이 경우 Secure 속성이 필요하다.

Set-Cookie: id=abc; SameSite=Strict;
Set-Cookie: id=abc; SameSite=None; Secure;

🍪 쿠키 규정과 법적 이슈

• 쿠키 사용에는 여러 법적 규정이 적용된다. 예를 들어, 유럽연합의 GDPR과 ePrivacy Directive, 그리고 캘리포니아 소비자 프라이버시 법(CCPA) 등이 있다.
• 쿠키 규정에 따라 쿠키 사용 고지 및 사용자의 동의를 받아야 하며, 일부 쿠키를 받지 않아도 사이트를 사용할 수 있어야 한다.

---