[11장] 클라이언트 식별과 쿠키

[eunbc]

No description provided.

[annahxxl]

개별 접촉

• HTTP는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 프로토콜이다
• 개인화된 서비스를 제공하는 방식
  • 개별 인사
  • 사용자 맞춤 추천
  • 저장된 사용자 정보
  • 세션 추적

쿠키

• 사용자를 식별하고 세션을 유지하는 방식 중에서 현재까지 가장 널리 사용하는 방식

쿠키의 타입

• 세션 쿠키
  • 사용자가 사이트를 탐색할 때, 관련된 설정과 선호 사항들을 저장하는 임시 쿠키
  • 사용자가 브라우저를 닫으면 삭제
• 지속 쿠키
  • 사용자가 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 이름을 유지하려고 사용
  • 디스크에 저장되어, 브라우저를 닫거나 컴퓨터를 재시작하더라도 남아있다

→ Discard 파라미터가 설정되어 있거나, 파기되기까지 남은 시간을 가리키는 Expires 혹은 Max-Age 파라미터가 없으면 세션 쿠키가 된다

쿠키는 어떻게 동작하는가

• 쿠키는 임의의 이름=값 형태의 리스트
• 서버는 Set-Cookie와 같은 헤더를 응답 헤더에 기술하여 사용자에게 전달

쿠키 구성요소 (Version 0 쿠키 - 넷스케이프 쿠키)

• 이름=값(필수)
• Expires: 쿠키의 생명주기를 가르키는 날짜 문자열, 사용할 수 있는 타임 존은 GMT뿐
• Domain: 해당 속성에 기술된 서버 호스트 명으로만 쿠키를 전송, 서버의 호스트를 기본으로 사용
• Path: 서버에 있는 특정 문서에만 쿠키 할당
• Secure: HTTP가 SSL 보안 연결을 사용할 때만 쿠키 전송

쿠키와 캐싱

• 캐시되지 말아야 할 문서가 있다면 표시하라
  • ex) Set-Cookie 헤더를 제외하고 캐시를 해도 될 경우, Cache-Control: no-cache=”Set-Cookie”
• Set-Cookie 헤더를 캐시 하는 것에 유의하라
  • 같은 Set-Cookie 헤더를 여러 사용자에게 보내게 되면, 사용자 추적에 실패할 것이다
• Cookie 헤더를 가지고 있는 요청을 주의하라
  • 요청이 Cookie 헤더와 함께 오면, 결과 콘텐츠가 개인정보를 담고 있을 수도 있다는 힌트다

[byulcode]

11.1 개별 접촉

HTTP 특징

• 상태가 없다(stateless) - 매 요청은 일회성이고 독립적으로 처리된다.
• 요청과 응답으로 통신한다.

⇒ 웹 서버는 요청을 보낸 사용자를 식별하거나, 연속적인 요청을 추적하기 위해 약간의 정보를 이용할 수 있다.

개인화

• 개별 인사
• 사용자 맞춤 추천
• 저장된 사용자 정보
• 세션 추적 (ex. 장바구니) - HTTP는 상태가 없기 때문에 상태 유지를 위해 HTTP 트랜잭션을 식별할 방법이 필요하다

11.2 헤더

사용자에 대한 정보를 전달하는 HTTP 헤더

• From : 사용자의 이메일 주소
  • 로봇, 스파이더는 웹 마스터가 항의 메일을 보낼 수 있도록 메일 주소를 기재
  • 악의적인 서버가 이메일 주소를 모아서 스팸 메일을 발송하기도 함
• User-Agent : 사용자의 브라우저 이름, 버전 정보
  • 브라우저의 속성에 맞춰 콘텐츠를 최적화하는데 유용함
• Referer : 사용자가 현재 페이지로 유입하게 한 웹페이지 URL
  • 사용자의 웹 사용 행태 분석

⇒ 특정 사용자를 식별하기엔 역부족!

• Authorization : 사용자 이름과 비밀번호
• Client-ip : 클라이언트의 IP 주소
• X-Forwarded-For : 클라이언트의 IP 주소
• Cookie : 서버가 생성한 ID 라벨

11.3 클라이언트 IP 주소

• 사용자 식별에 클라이언트 IP 주소 사용

• HTTP 헤더에X → HTTP 요청을 보내 반대쪽 TCP 커넥션의 IP주소를 알아냄

  문제점

  • 클라이언트 IP 주소는 컴퓨터를 가리킨다.(여러 사용자가 한 컴퓨터 이용시 식별 불가)
  • ISP는 동적으로 IP주소를 할당한다.
  • 많은 사용자가 보안을 위해 NAT 방화벽을 사용한다. NAT 장비들은 실제 IP 주소를 내부에서 사용하는 하나의 방화벽 IP주소로 변환한다.
  • 서버가 프락시나 게이트웨이에 연결되어 있는 경우 클라이언트의 IP주소 대신 프락시 서버의 IP 주소를 본다. (프락시 확장 헤더(Client-ip, X-Forwarded-For)를 사용할 수도 있지만 모든 프락시가 그렇게 하지는 않는다.)

11.4 사용자 로그인

• WWW-Authenticate와 Authorization 헤더를 사용해 웹 사이트에 사용자 이름을 전달한다.
• 서버는 401 Login Required 응답과 WWW-Authenticate 헤더를 반환해 로그인 요청한다.
• 로그인 후 요청부터는 서버가 요청하지 않아도 사용자 이름과 비밀번호를 포함해 전달해 세션이 진행되는 내내 사용자에 대한 식별을 유지한다

11.5 뚱뚱한 URL

• 사용자가 처음 웹사이트에 방문하면 유일한 ID가 생성된다.

• URL 처음이나 끝에 ID를 추가하여 사용자를 추적하는 뚱뚱한 URL을 만든다.

• 서버는 클라이언트를 뚱뚱한 URL로 리다이렉트 시킨다.

  문제점

  • 못생긴 URL로 사용자에게 혼란을 줌
  • 공유 불가 : 공유시 개인 정보 함께 공유됨
  • 캐시 접근 불가 : URL이 달라지기 때문에 기존 캐시에 접근 불가
  • 서버 부하 증가: 뚱뚱한 URL에 해당하는 각 페이지들을 새로 그려야 함
  • 세션 지속 불가: 로그아웃하면 모든 정보를 잃음

11.6 쿠키

• 사용자를 식별하고 세션을 유지하는 방식 중 가장 널리 사용됨

• 캐시와 충돌할 수 있어 쿠키의 내용물을 캐싱하지 않음.

  세션 쿠키 Session Cookie

  • 사용자의 설정과 선호 사항들을 저장하는 임시 쿠키
  • 브라우저를 닫으면 삭제됨

  지속 쿠키 Persistent Cookie

  • 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 이름을 유지하기 위해 사용
  • 디스크에 저장되어 브라우저나 컴퓨터를 재시작해도 유지됨

  쿠키 동작

  1. 최초 통신에는 사용자에 대한 정보가 없다.
  2. 서버는 사용자를 식별하기 위한 유일한 값을 이름=값 태의 리스트로 Set-Cookie 혹은 Set-Cookie2 같은 헤더에 저장하여 응답한다.
  3. 브라우저는 헤더로 받은 쿠키 정보를 쿠키 데이터베이스에 저장한다.
  4. 두번째 요청부터는 해당 사용자에게 할당했던 쿠키를 헤더에 기술해 전송한다.

[park0jae]

HTTP 헤더

• From: 사용자의 이메일 주소
• User-Agent : 사용자의 브라우저
• Referer : 사용자가 현재 링크를 타고 온 근원 페이지
• Authorization : 사용자 이름과 비밀번호
• Client-ip : 클라이언트 IP 주소
• X-Forwarded-For : 클라이언트의 IP 주소
• Cookie : 서버가 생성한 ID Label

From 헤더

• 각 사용자 이메일 주소로 사용자를 식별할 수 있음
• 악의적인 서버가 이메일을 모아 스팸 메일을 발송하는 문제로 From 헤더를 보내는 브라우저는 많지 않음

User-Agent 헤더

• 사용자가 쓰고 있는 브라우저 이름과 버전 정보, 어떤 경우에는 운영체제에 대한 정보를 포함
• 사용자 식별에는 딱히.. 도움이 되진 않음

Referer

• 사용자가 현재 페이지로 유입하게 한 웹 페이지의 URL을 가리킴
• Referer 헤더 자체만으로 사용자를 식별은 할 수 없지만, 사용자가 전에 방문했던 페이지를 알 수 있음
• 사용자의 웹 사용 형태나 취향 파악에 사용

→ From, User-Agent, Referer 헤더는 확실히 식별하기엔 정보가 부족하다.

클라이언트 IP 주소

• 사용자가 확실한 IP 주소를 갖고 있고 IP는 좀처럼 바뀌지 않으며 웹 서버가 요청마다 클라이언트의 IP 주소를 알 수 있다면 문제없이 동작
• 클라이언트 IP 주소는 보통 HTTP 헤더에 없지만 웹 서버는 HTTP 요청을 보내는 TCP 커넥션의 반대쪽 IP를 알아낼 수 있다.

→ 클라이언트 IP 주소로 사용자를 식별하는 방법의 약점 ?

- 클라이언트 IP 주소는 사용자가 아닌 사용자 컴퓨터를 가리킨다. 여러명이 한 컴퓨터 이용 -> 식별 불가...

- ISP(인터넷 서비스 제공자)는 사용자가 로그인하면 동적으로 IP를 할당한다.

사용자 인증 과정의 전체적인 Flow

• 서버 입장에서 WWW-authenticate 헤더를 이용해 인증하라고 요청해주는 모습
• 클라이언트는 Authorization 헤더를 이용해, 사용자에 대한 인증이 이루어지는 모습
• 문제는 ? 사용자 입장에서 웹 사이트를 옮겨 다니면 매번 인증해야 하는 아주 귀찮은 일..

→ 어떻게 하면 쉽게 할 수 있을까 ?

쿠키

• 세션 쿠키 (Session Cookie)
  • 사용자가 사이트를 탐색할 때 관련한 설정을 저장하는 임시 쿠키
  • 브라우저 닫으면 삭제됨
• 지속 쿠키 (Persistent Cookie)
  • 지속 쿠키는 세션과는 다르게 컴퓨터를 재시작해도 유지함

브라우저는 수천 수백개의 쿠키를 가질 수 있지만, 브라우저가 쿠키 전부를 모든 사이트에 보내지는 않음

• 보통은 2~3개의 쿠키만 보낸다.

• 쿠키를 모두 전달하면 성능 저하

• 쿠키는 대부분 key/value로 저장되어 있어 대부분 사이트에서는 인식하지 않는 무의미한 값

• 잠재적인 개인정보 문제 야기

• 쿠키 Domain 속성

  • 서버는 쿠키를 생성할 때 Set-Cookie 응답 헤더에 Domain 속성을 기술해 어떤 사이트가 그 쿠키를 읽을 수 있는지 제어

Set-Cookie: user="Tom"; domain="naver[.com](http://yahoo.com/)"

• 쿠키 Path 속성
  • 웹 사이트 일부에만 쿠키를 적용할 수도 있다. URL 경로의 앞부분을 가리키는 Path 속성을 기술해 해당 경로에 속하는 페이지에만 쿠키를 전달한다.

쿠키의 구성요소

• 현재 사용되는 쿠키 명세에는 Version 0 (’넷스케이프 쿠키’)과 Version 1 쿠키 (폐기되어 사용 X)가 있음

Version 0 (넷스케이프) 쿠키

• 최초의 쿠키 명세는 넷스케이프가 정의했다.
• Version 0 쿠키는 Set-Cookie 응답 헤더와 Cookie 요청 헤더와 쿠키를 조작하는데 필요한 필드들을 정의하였다.

# version 0 쿠키의 형태
Set-Cookie: name=value [; expires=date][; path=path] [; domain=domain][; secure]

• Version 0 쿠키의 Set-Cookie 헤더

  • 이름=값
    • ex) Set-Cookie: customer=Mary
  • Expires
    • ex) Set-Cookie: foo=bar; expires=Wednesday, 09-Nov-99 23:12:40 GMT
  • Domain
    • 기술된 도메인을 사용하는 서버 호스트명만 쿠키 전송
    • ex) Set-Cookie: domain="joes-hardware.com"
  • Path
    • 특정 경로에만 쿠키 할당
    • ex) Set-Cookie: path=/orders
  • Secure
    • HTTPS 연결을 사용할 때만 쿠키를 전송
    • ex) Set-Cookie: private_id=519; secure

• 업그레이드된 Version 1의 Set-Cookie2 헤더

  • 넷스케이프 표준보다 더 많은 속성이 있으며 Version 0 시스템과도 호환이 가능
  • Version
    • (필수 속성) 쿠키 명세의 버전을 가리키는 정수값
  • Comment
    • (선택 속성) 서버가 쿠키를 사용하려는 의도를 기술
  • CommentURL
    • (선택 속성) 서버가 쿠키를 사용하려는 목적과 정책에 대해 기술된 웹 페이지 링크
  • Discard
    • (선택 속성) 클라이언트 프로그램이 종료될 때 쿠키를 삭제하라는 헤더
  • Domain
    • 기존 Domain과 동일
  • Max-Age
    • (선택 속성) Expires와 목적은 유사하나, 실제 쿠키의 생명주기를 초 단위로 산정한 정수값
  • Path
    • 기존 Path와 동일
  • Port
    • (선택 속성) 특정 Port에 해당하는 서버로만 쿠키 전달
  • Secure
    • 기존 Secure와 동일

쿠키의 캐싱 전략

기본적인 원칙들은

• 캐시되지 말아야 할 문서가 있다면 표시하라
  • 문서가 Set-Cookie 헤더를 제외하고 캐시해도 되는 경우 → Cache-Control : no-cache=”Set-Cookie” 명시
  • 캐시를 해도 되는 문서 → Cache-Control:public 을 사용하여 웹의 대역폭을 절약하자.
• Set-Cookie 헤더를 캐시하는 것에 유의하라
  • 같은 Set-Cookie 헤더를 여러 사용자에게 보내면 → 사용자 추적에 실패함
  • 일부 캐시는 응답 저장 이전에 Set-Cookie를 제거함 → 해당 캐시 데이터를 받은 클라이언트는 문제 발생
  • Cache-Control: must-revalidate, max-age=0 헤더를 추가하여 캐시가 모든 요청마다 원 서버와 재검사를 하도록 할 수 있음
• Cookie 헤더를 가지고 있는 요청을 주의하라
  • 요청이 Cookie 헤더와 함께 오면, 결과 콘텐츠가 개인정보를 담고 있을 수도 있다는 뜻

[KarmaPol]

클라이언트 식별

개별 접촉

HTTP는 익명, 무상태 프로토콜이지만
웹서버는 사용자를 추적하기 위해 약간의 정보를 이용할 수 있다

사이트 개인화

• 개별 인사
• 사용자 맞춤 추천
• 저장된 사용자 정보
• 세션 추적

사용자 식별 기술들

HTTP 헤더

• From 사용자 이메일 주소
  악의적으로 이메일 주소가 이용될 수 있음
• User-Agent 사용자 브라우저 정보
• Referer 사용자의 근원 페이지
  사용자 취향 등을 알아내기 용이함

클라이언트 IP 주소

웹 서버는 HTTP 요청을 보낸 반대쪽 TCP 커넥션의 주소를 알 수 있다
하지만,

• IP는 컴퓨터 자체를 가리키므로 사용자 식별에 어려움이 있다
• IP는 동적으로 할당된다
• NAT 장비를 통해 IP주소를 숨긴다
• 프락시 서버의 주소를 가리킨다
  -> 인트라넷 등에서는 유용한 방법

사용자 로그인

로그인을 요구해서 명시적으로 식별 요청 가능

뚱뚱한 URL

URL 마다 상태 정보를 추가해 확장 (쇼핑 카트, 프로필 등)

문제점

• 못생긴 URL
• 상태정보를 포함하므로 공유하지 못하는 URL
• 캐시를 사용할 수 없음 -> 서버 부하 가중
• 이탈 시 초기화
• 세션 간 지속성 없음

쿠키

사용자 식별, 세션을 유지하는 방식 중 가장 널리 쓰이는 방식

• 쿠키는 캐시와 충돌할 수 있으므로 캐싱 하지 않는다

쿠키 타입

• 세션 쿠키
  사용자가 사이트 탐색 시 관련 설정과 선호 사항 저장하는 임시 쿠키
• 지속 쿠키
  디스크에 저장되어 사이트 정보나 로그인 이름 유지에 사용

쿠키 동작

서버의 사용자 추적 용으로는 단순 식별 정보만 포함
서버 응답 헤더 Set-Cookie : name = "Brian" 클라이언트 쿠키 지정

사이트 마다 다른 쿠키들

브라우저가 갖는 수백 개의 쿠키를 사이트 마다 보내지 않는다 -> 두개, 세 개의 쿠키만을 보낸다

• 도메인 속성
  Set-cookie: user="mary"; domain = "airbnb.com"
  지정한 도메인으로 끝나는 사이트 방문 시 클라이언트는 쿠키 전송
• Path 속성
  URL 특정 Path만 지정 가능

쿠키와 세션 추적

1. 브라우저가 루트 페이지 요청
2. 서버는 전자 상거래 URL로 리다이렉트
3. 브라우저는 리다이렉트 URL로 요청
4. 서버는 두개의 세션 쿠키 기술하고 새로운 URL로 리다이렉트
5. 클라이언트는 새로운 URL에 쿠키와 함께 요청
6. 서버는 home.html 페이지로 리다이렉트하고 새로운 두개 쿠키 첨부
7. 클라이언트는 home.html 가져오고 총 4개의 쿠키 전달
8. 서버는 콘텐츠를 보낸다

쿠키와 캐싱

쿠키는 개인 정보가 있을수 있으므로 캐싱에 주의해야 한다

• 캐시되지 말아야 할 문서가 있으면 표시하라
• Set-Cookie 헤더를 캐시하면 사용자 추적이 어렵다
• Cookie 헤더가 포함된 요청에 응답으로 오는 문서를 캐시할때 주의하라

쿠키와 개인정보

쿠키는 그 자체로 보안 상 위험한 것은 아니다

• 개인 정보는 원격 DB에 저장하고 키 값을 쿠기에 저장하자

[eunbc]

개별 접촉

1. HTTP 는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 프로토콜이지만, 현대의 웹 사이트들은 개인화된 서비스를 제공하고 싶어하기 때문에 HTTP 가 사용자를 식별할 수 있어야 함

---

어떻게 클라이언트를 식별하나?

HTTP 헤더

1. 사용자에 대한 정보를 전달하는 HTTP 요청헤더
2. From : 사용자의 이메일 주소
3. User-Agent : 사용자의 브라우저, 버전 정보, 운영체제 정보
4. Referer : 현재 페이지로 유입하게 한 근원 페이지 URL , 이전에 어떤 페이지를 방문했는지 알려줌으로써 사용자의 취향 파악에 용이

클라이언트 IP 주소

1. 초기 웹은 IP 주소가 절대적이었기 때문에 IP를 클라이언트 정보로 사용자를 식별했다
2. 하지만, 최근 IP는 동적으로 할당되거나, 보안을 위해 NAT 방화벽을 지나서 IP 주소가 다르거나, 프락시 또는 게이트웨이를 지나므로 IP주소로 사용자를 식별하는 방식은 한계가 있다

사용자 로그인

1. 사용자 이름과 비밀번호로 로그인하여 사용자에게 명시적으로 식별 요청을 한다
2. Authorization 헤더 : 한번 로그인하면 모든 요청에 식별 정보 토큰을 함께 보냄

뚱뚱한 URL

1. 사용자의 상태 정보를 URL에 포함
2. 하지만 이 URL은 못생겼고, 공유하지 못하고, 캐시를 사용할 수 없고, 이탈할 수 있는 문제가 있는 등 여러가지 심각한 문제가 있다

쿠키

1. 쿠키는 사용자를 식별하고 세션을 유지하는 방식 중에서 널리 사용하는 방식임
2. 브라우저에 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때마다 그 정보를 함께 전송한다
3. 쿠키의 종류
   1. 세션쿠키 : 임시 설정 및 선호 사항을 저장하는 임시 쿠키, 브라우저를 닫으면 삭제됨
   2. 지속쿠키 : 디스크에 저장되어 브라우저를 닫거나 컴퓨터를 재시작하더라도 남아있음. 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 정보를 유지하려고 사용
4. 쿠키의 구성요소

   1. Version 0 쿠키

      1. Set-Cookie 응답 헤더 속성

      이름=값	필수 속성, 웹 서버에 다시 방문하면 읽어올 어떤 조합이든 만들 수 있다.
      Expires	선택 속성, 쿠키의 생명주기를 가리키는 날짜 문자열, Expires가 없다면 사용자 세션이 끝날 때 파기됨
      Domain	선택 속성, 이 속성에 기술된 도메인을 사용하는 서버 호스트명으로만 쿠키를 전송한다
      Path	선택 속성, 서버에 있는 특정 문서에만 쿠키를 할당할 수 있다
      Secure	선택, 이 속성이 포함되어 있으면, 쿠키는 HTTP 가 SSL 보안 연결을 사용할 때만 쿠키를 전송한다.

      1. Cookie 요청헤더 : 클라이언트가 서버에 요청을 보낼 때, Domain, Path, Secure 필터들이 현재 요청하려고 하는 사이트에 들어맞으면서 아직 유효한 쿠키들을 함께 보냄. 모든 쿠키는 Cookie 헤더에 한데 이어 붙여 보낸다.

   2. Version 1 쿠키 : Version 0 쿠키의 확장으로, 널리 쓰이지는 않음

5. 쿠키 트랜잭션과 관련된 문서를 캐싱하는 것에 주의해야 한다. 이전 사용자의 쿠키가 다른 다용자에게 할당되거나, 개인 정보 노출 위험이 있음

[kimday0326]

개별 접촉

HTTP의 특징

• 익명
• 무상태(stateless)
• 요청과 응답으로 통신하는 프로토콜

웹서버가 이용할 수 있는 약간의 정보

1. 개별 인사
2. 사용자 맞춤 추천
3. 저장된 사용자 정보
4. 세션 추적

HTTP 헤더

• From
  -> 사용자의 이메일 주소
• User-Agent
  -> 사용자의 브라우저
• Referer
  -> 사용자가 현재 페이지로 유입된 웹페이지의 URL

클라이언트 IP 주소

클라이언트의 IP 주소를 이용하여 사용자를 식별하는 것은 다음과 같은 약점을 가진다.

1. 동적 IP 주소: 많은 인터넷 서비스 제공업체(ISP)는 사용자에게 동적으로 IP 주소를 할당한다. 이는 사용자의 IP 주소가 정기적으로 변경될 수 있음을 의미하며, 고정된 IP 주소를 기반으로 한 보안 조치는 신뢰성이 떨어질 수 있다.

2. NAT(Network Address Translation)와 공유 IP 주소: NAT를 사용하는 환경에서는 여러 장치들이 인터넷에 접근할 때 같은 공용 IP 주소를 공유할 수 있으므로 식별이 어렵다.

3. 프록시 서버와 VPN: 사용자들은 프록시 서버나 VPN을 사용하여 실제 IP 주소를 숨기고 다른 IP 주소를 통해 인터넷에 접근할 수 있기 때문에 개별 사용자의 식별이 어렵다.

4. 모바일 네트워크와 IP 변경: 모바일 장치 사용자는 이동 중에 여러 네트워크에 연결될 수 있으며, 이 과정에서 IP 주소가 자주 변경된다.

사용자 로그인

웹 서버는 사용자 이름과 비밀번호로 사용자를 식별 할 수 있다. 401 Login Required 응답과 Authroization 헤더를 이용해 로그인을 처리한다.

뚱뚱한 URL

URL 처음이나 끝에 ID를 추가함으로써 뚱뚱한 URL을 활용할 . 수있다.

• 못생긴 URL
• 공유하지 못하는 URL
• 캐시를 사용할 수 없음
• 서버 부하 가중
• 이탈
• 세션 간 지속성의 부재

쿠키

1. 쿠키의 타입
   • 세션 쿠키: 사용자가 브라우저를 닫을 때까지 유지되는 임시 쿠키.
   • 지속 쿠키: 사용자 디스크에 저장되어 브라우저를 재시작해도 유지되는 쿠키.
2. 쿠키의 동작 방식
   • 사용자가 웹사이트를 방문하면, 서버는 쿠키에 사용자 식별 값을 할당하고, 이를 Set-Cookie 헤더를 통해 사용자에게 전달한다.
   • 브라우저는 이 쿠키를 저장하고, 같은 사이트를 재방문할 때 Cookie 헤더에 쿠키를 담아 서버에 전송한다.
3. 사이트마다 다른 쿠키
   • 브라우저는 특정 사이트와 관련된 쿠키만을 해당 사이트에 전송한다.
   • 쿠키의 Domain과 Path 속성을 통해 어떤 사이트와 경로에서 쿠키를 사용할지 제어한다.
4. 쿠키와 캐싱
   • 쿠키와 관련된 문서를 캐싱하는 것은 쿠키의 정보가 다른 사용자에게 노출될 위험이 있기 때문에, Set-Cookie 헤더가 있는 문서는 일반적으로 캐싱하지 않는다.
5. 쿠키, 보안, 개인정보
   • 쿠키는 자체적으로 큰 보안 위험을 가지지 않으나, 광고 사이트에서 사용자 추적을 위해 지속 쿠키를 오용하는 등의 행위는 조심해야한다.