[HTTP 완벽가이드 11장] 클라이언트 식별과 쿠키

---

3부.HTTP : 식별, 인가, 보안

---

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

웹 서버는 서로 다룬 수천개의 클라이언트들과 동시에 통신한다. 이 서버들은 익명의 클라이언트로부터 받는 모든 요청을 처리하느 것뿐만 아니라 
서버와 통신하고 있는 클라이언트를 추적해야 할 수도 있다. 이 장에서는 서버가 통신하는 대상을 식별하는데 사용하는 기술을 알아본다.

---

11.1 개별 접촉

• HTTP는 익명으로 사용하며 상태가 없고 요쳥과 응답으로 통신하는 프로토콜이다. 서버는 클라이언트가 보낸 요청을 처리하고 나서 그 응답을 클라이언트로
  전송한다.

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

  개별 인사

  • 개인 사용자에게 특화된 환영 메세지나 페이지 내용을 만든다.

  사용자 맞춤 추천

  • 고객의 생일이나 중요한 날이 다가오면 특별한 맞춤 제품을 제시한다.

  저장된 사용자 정보

  • 쇼핑을 더 편하게 할 수 있도록 저장된 사용자 정보를 사용한다.

  세션 추적

  • HTTP 트랜잭션은 상태가 없다. 각 요청에 독립적으로 일어난다.
  • 많은 웹사이트에서 사용자가 사이트와 상호작용할 수 있게 사용자의 상태를 남긴다. (장바구니 기능 등)
  • 이렇게 상태를 유지하려면, 웹 사이트는 각 사용자에게서 오는 HTTP 트랜잭션을 식별할 방법이 필요하다.

• 이 장에서는 HTTP 사용자를 식별하는 기술들을 정리한다.

• 초기 웹 사이트 설계자들은 사용자를 식별하는 그들만의 기술을 개발하였다. 실용주의자였던 초기 웹 사이트 설계자들은
  사용자를 식별하는 기술들을 개발하였다.

• 각 기술의 장단점과 사용자 식별 기술을 논의한다.

  • 사용자 식별 관련 정보를 전달하는 HTTP 헤더들
  • 클라이언트 IP 주소 추적으로 알아낸 IP 주소로 사용자를 식별
  • 사용자 로그인 인증을 통한 사용자 식별
  • URL에 식별자를 포함하는 기술인 뚱뚱한(Fat) URL
  • 식별 정보를 지속해서 유지하는 강력하면서도 효울적인 기술인 쿠키

11.2 HTTP 헤더

• 사용자에 대한 정보를 전달하는 가장 일반적인 일곱가지 HTTP 요청 헤더

헤더 이름	헤더 타입	설명
From	요청	사용자의 이메일 주소
User-Agent	요청	사용자의 브라우저
Referer	요청	사용자가 현재 링크를 타고 온 근원 페이지
Authorization	요청	사용자의 이름과 비밀번호(뒤에서 다룸, 발전된 헤더)
Client-ip	확인(요청)	클라이언트이 IP주소(뒤에서 다룸, 발전된 헤더)
X-Forwarded-For	확인(요청)	클라이언ㅌ의 IP주소(뒤에서 다룸, 발전된 헤더)
Cookie	확인(요청)	서버가 생성한 ID 라벨(뒤에서 다룸, 발전된 헤더)

From

• 사용자의 이메일 주소를 포함한다. 이상적으로는 각 사용자가 서로 다른 이메일 주소를 가지므로, From 헤더로 사용자를 식별할 수 있다.

• 악의적인 서버가 이메일 주소를 모아서 스팸 메일을 발송하는 문제가 있어서 From 헤더를 보내는 브라우저는 많지 않다.

• 로봇이나 스파이더는 데이터를 수집하는 과정에서 본의 아니게 웹 사이트에 문제를 일으켰을 때, 해당 웹 사이트의 웹 마스터가 항의
  메일을 보낼 수 있도록 From 헤더에 이메일 주소를 기술한다.

  User-Agent

• 사용자가 쓰고 있는 브라우저의 이름과 버전 정보, 어떤 경우에는 운영체제에 대한 정보까지 포함하여 서버에게 알려준다.

• 이는 특정 브라우저에서 제대로 동작하도록 그것들의 속성에 맞추어 콘텐츠를 최적화하는 데 유용할 수 있지만, 특정 사용자를 식별하는 데는
  크게 도움되지 않는다.

  메시지

  크롬
  

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

익스플로러

User-Agent: Mozilla/5.0 (Windows NT 10.0; Trident/7.0; rv:11.0) like Gecko

  <Strong>Referer
  - 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL을 가르킨다.
  - Referer헤더 자체만으로 사용자를 식별할 순 없지만, 사용자가 이전에 어떤 페이지에 방문했었는지 알려준다.
  - 사용자의 웹 사용 행태나 사용자의 취향을 더 잘 파악할 수 있다.  

<Strong> From, User-Agent, Referer 헤더들은 확실히 식별하기에는 부족한 정보를 가진다.

### 11.3 클라이언트의 IP 주소
- 초기 웹 선구자들은 사용자 식별에 IP 주소를 사용하려 했다. 이 방식은 사용자가 확실한 IP 주소를 가지고 있고, 그 주소가 좀처럼 
  바뀌지 않고, 웹 서버는 요청마다 클라이언트의 IP 주소를 알 수 있다면 문제없이 동작한다.
- 클라이언트의 IP 주소는 보통 HTTP 헤더에 없지만 (표준은 아니지만) 웹 서버는 HTTP 요청을 보내는 반대쪽 TCP 커넥션의 IP 주소를 
  알아낼 수 있다.
- 안타깝게도 클라이언트 IP 주소로 사용자를 식별하는 방식은 다음과 같은 한계를 지닌다.
  - 클라이언트 IP 주소는 사용자가 아닌, 사용하는 컴퓨터를 가르킨다. 이는 여러 사용자가 같은 컴퓨터를 사용한다면 식별이 불가하다.
  - 많은 인터넷 서비스(ISP)는 사용자가 로그인하면 동적으로 IP 주소를 할당한다. 로그인한 시간에 따라 사용자는 매번 다른 주소를 받는다.
  - 보안을 강화하고 부족한 주소들을 관리하려고 많은 사용자가 네트워크 주소 변환 방화벽을 통해 인터넷을 사용한다. 이 NAT 장비들은 클라이언트의
    실제 IP 주소를 방화벽 뒤에 숨기고, 클라이언트의 실제 IP 주소를 내부에서 사용하는 하나의 방화벽 IP 주소(그리고 다른 포트 번호)로 변환한다.
  - 보통, HTTP 프락시와 게이트웨이는 원 서버에 새로운 TCP 연결을 한다. 웹 서버는 클라이언트의 IP 주소 대신 프락시 서버의 IP 주소를 본다.
    일부 프락시는 원본 IP 주소를 보존하려고 Client-IP나 X-forwarded-For HTTP 같은 확장 헤더를 추가하여 이 문제를 해결하려 했지만, 모든 
    프락시가 이런 식으로 동작하진 않는다.


### 11.4 사용자 로그인
- IP 주소로 사용자를 식별하려는 수동적인 방식보다, 웹 서버는 사용자 이름과 비밀번호로 인증할 것을 요구해서 사용자에게 명시적으로 식별 요청 한다.
- 웹 사이트에서 로그인이 더 쉽도록 HTTP는 WWW-Authenticate와 Authorization 헤더를 사용해 웹 사이트에 사용자 이름을 전달하는 
  자체적인 체계를 가지고 있다.
- 한번 로그인하면, 브라우저는 사이트로 보내는 모든 요청에 이 로그인 정보를 함께 보내므로 웹 서버는 로그인 정보를 항상 확인할 수 있다.
- 서버에서, 사용자가 사이트에 접근하기 전에 로그인을 시키고자 한다면 HTTP 401 Login Required 응답 코드를 브라우저에 보낸다.
- 브라우저는 로그인 대화상자를 보여주고, 다음 요청부터 Authorization 헤더에 그 정보를 기술하여 보낸다.

<img src="http://tlog.tammolo.com/static/95556f737a8c799474cff53c7c4cfb7a/3e1c2/Untitled-7203faa4-923b-4312-b73b-23dd0c3f978b.png" width=120%>

  - 그림 a에서 브라우저는 www.github.com/m3252 사이트로 요청한다.
  - 사이트는 사용자의 식별정보를 알지 못하므로, 그림 b와 같이 서버는 401 Login Required HTTP 응답 코드와 WWW-Authorization 헤더를
    반환하여 로그인 하라 요청한다. 이는 브라우저에 로그인 대화 상자를 띄우게 한다.
  - 사용자가 사용자 이름과 비밀번호를 입력하고 브라우저는 기존 요청을 다시 보내서 사요자 식별을 시도한다.
  - 이제 서버는 사용자의 식별정보를 안다.
  - 이 시점 이후의 요청에 대해서, 브라우저는 서버로부터 사용자 식별 정보를 요청 받므녀 서베에서 오는 요청에 대해 자동으로 사용자 이름과 비밀번호
    를 포함하며, 심지어 요청하지 않았을 때도 전달한다.
  - 이는 사이트에 한 번만 로그인하면, 브라우저는 요청마다 해당 사용자의 식별정보 토큰을 Authorization 헤더에 담아 서버로 전송해서, 한 세션이
    진행되는 내내 그 사용자에 대한 식별을 유지한다.

하지만 웹 사이트 로그인은 귀찮은 일이다. 예를 들어 프레드라는 사용자는 사이트를 옮겨다닐 때마다 각 사이트에 로그인을 해야 한다. 더 큰 문제는,
프레드가 사이트마다 서로 다른 사용자 이름과 비밀번호를 기억해야 한다는 것이다. 사이트를 돌아다니다보면 프레드가 좋아하는 사용자 이름인 Fred는
다른 누군가가 선점했을 것이고, 어떤 사이트는 사용자 이름과 비밀번호 길이와 조합 규칙이 다를 것이다. 곧 프레드는 인터넷 사용을 포기할 것이다.

````

이 문제의 해결 방안이다.

11.5 뚱뚱한 URL

• 어떤 웹 사이트는 사용자의 URL 마다 버전을 기술하여 사용자를 식별하고 추적하였다. 보통, URL은 URL 경로의 처음이나 끝에 어떤 상태
  정보를 추가해 확장한다.

• 사용자가 그 사이트를 돌아다니면, 웹 서버는 URL에 있는 상태 정보를 유지하는 하이퍼링크를 동적으로 생성한다.

• 사용자의 상태 정보를 포함하고 있는 URL을 뚱뚱한 URL이라고 부른다.

  아마존의 뚱뚱한 URL

  • 사용자에게 할당된 식별 번호 002-1145265-8016838를 각 URL 뒤에 붙여서 사용자를 추적한다.

    <a href=/exec/obidos/tg/browse/-/229220/ref=gr_gifts/002-1145265-8016838></a>

• 웹 서버와 통신하는 독립적인 HTTP 트랜잭션을 하나의 '세션' 혹은 '방문'으로 묶는 용도로 뚱뚱한 URL을 사용할 수 있다.

• 사용자가 처음 웹 사이트에 방문하면 유일한 ID가 생성되고, 그 값은 서버가 인식할 수 있는 방식으로 URL에 추가되며, 서버는 클라리언트를 이 뚱뚱한
  URL로 리다이렉트 시킨다. 서버가 뚱뚱한 URL을 포함한 요청을 받으면 사용자의 아이디와 관련된 추가 정보를 찾아서 밖으로 향하는 모든 하이퍼링크에
  뚱뚱한 URL로 바꾼다.

• 뚱뚱한 URL은 사이트를 브라우징하는 사용자를 식별하는 데 사용할 수 있다. 하지만 이 기술은 여러 심각한 문제가 있다.

  못생긴 URL

  • 브라우저에 보이는 뚱뚱한 URL은 새로운 사용자들에게 혼란을 준다.

  공유하지 못하는 URL

  • 뚱뚱한 URL은 특정 사용자와 세션에 대한 상태 정보를 포함한다. 만약 그 주소를 누군가에게 보내면, 당신의 누적된 개인 정보를 공유하게 된다.

  캐시를 사용할 수 없음

  • URL로 만드는 것은, URL이 달라지기 때문에 기존 캐시에 접근할 수 없다는 것을 의미한다.

  서버 부하 증가

  • 서버는 뚱뚱한 URL에 해당하는 HTML 페이지를 다시 그려야 한다.

  이탈

  • 사용자가 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청해서 의도치 않게 뚱뚱한 URL 세션에서 이탈하기 쉽다.
  • 사용자는 서비스를 이용하는 동안, 사전에 세션 정보가 추가된 링크만을 사용해야 문제없이 동작한다.
  • 사용자가 이탈하게 되면 지금까지의 진척상항들(장바구니)이 초기화되고 다시 처음부터 시작해야 될 것이다.

  세션 간 지속성의 부재

  • 사용자가 특정 뚱뚱한 URl을 북마킹하지 않는 이상, 로그아웃하면 모든 정보를 잃는다.

11.6 쿠키

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

• 앞서 설명한 기술들이 가지고 있던 문제점을 겪지는 않지만, 쿠키만으로 하기 힘들일은 앞의 기술들을 함께 사용하기도 한다.

• 쿠키는 매우 중요한 웹 기술일 뿐만 아니라 새로운 HTTP 헤더를 정의하므로, 앞서 다룬 기술들보다 자세히 알아본다.

• 쿠키는 캐시와 출동할 수 있어서, 대부분의 캐시나 브라우저는 쿠키에 있는 내용물을 캐싱하지 않는다.

  1) 쿠키의 타입

  • 쿠키는 크게 세션 쿠키(Session Cookie)와 지속 쿠키(Persistent Cookie)로 나뉜다.
  • 세션 쿠키는 사용자가 사이트를 탐색할 때, 관련 설정과 선호 사항들을 저장하는 임시 쿠키다.
  • 세션 쿠키는 사용자가 브라우저를 닫으면 삭제된다.
  • 지속 쿠키는 삭제되지 않고 더 길게 유지될 수 있다.
  • 지속 쿠키는 디스크에 저장되어, 브라우저를 닫거나 컴퓨터를 재시작하더라도 남아있다.
  • 지속 쿠키는 사용자가 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 이름을 유지하려고 사용한다.
  • 두가지 타입의 쿠키의 차이점은 파기되는 시점 뿐이다.
  • 쿠키는 Discard 파라미터가 설정되어 있거나, 파기되기까지 남은 시간을 가리키는 Expires혹은 Max-Age 파라미터가 없으면 세션 쿠키다.

  2) 쿠키는 어떻게 동작하는가?

  • 쿠키는 서버가 사용자에게 붙이는 스티커와 같다.
  • 웹 사이트를 방문하면, 웹 사이트는 서버가 사용자에게 붙인 모든 스티커를 읽을 수 있다.
  • 처음 사이트에 방문한다면 웹 서버는 사용자에 대해 아무것도 모르지만, 다시 돌아왔을 떄, 해당 사용자를 식별하기 위한
    유일한 값을 쿠키에 할당한다.
  • 쿠키는 이름 = 값 형태의 리스트를 가지고, 그 리스트는 Set-Cooke 혹은 Set-Cookie2 같은 HTTP 응답 헤더에 기술되어 사용자에게 전달된다.
  • 쿠키는 어떤 정보든 포함할 수 있지만, 서버가 사용자 추적 용도로 생성한 유일한 단순 식별 번호만 포함하기도 한다.
  • 예를 들어 서버는 Set-cookie: id="123"; 라는 쿠키를 사용자에게 할당한다.
    • 서버는 이 쿠키 값으로 DB에서 사용자의 정보를 찾는데 사용할 수 있다.
    • 하지만 쿠키는 단순히 ID 번호에만 국한되지 않고, 많은 웹 서버가 정보를 쿠키에 유지하려고 한다.
  • 예를 들면 Cookie: name="Brian Totty"; phone="123-1234"라는 쿠키가 있다.
    • 브라우저는 서버로 온 Set-Cookie에 혹은 Set-Cookie2 헤더에 있는 쿠키 콘텐츠를 브라우저 쿠키 DB에 저장한다.
      (여러 나라에서 배송된 여행 가방에 붙은 스티커와 비슷하다.)
    • 사용자가 미래에 같은 사이트를 방문하면, 브라우저는 서버가 이 사용자에게 할당했던 쿠키를 Cookie 요청 헤더에 기술해 전송한다.

  3) 쿠키 상자: 클라이언트 측 상태

  • 쿠키의 기본적인 발상은 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때마다 그 정보를 함께 전송하게 하는 것이다.
  • 브라우저는 쿠키 정보를 저장할 책임이 있는데, 이 시스템을 '클라이언트 측 상태' 라고 한다.
  • 쿠키 명세에서 이것의 공식적인 일므은 HTTP 상태 관리 체계(HTTP state Management Mechanism)이다.

구글 크롬 쿠키

• 각 브라우저는 각기 다른 방식으로 쿠키를 저장한다. 구글 크롬은 Cookies라는 SQLite파일에 쿠키를 저장한다.

  

• 이 SQLite 파일에 있는 각 행이 쿠키 한개에 해당한다. 총 13개의 필드가 있는데 몇몇 주요 필드의 의미는 다음과 같다.

  creation_utc

  • 쿠키가 생성된 시점을 알려주는데, 그 값은 Jan 1, 1970 00:00:00 GMT로부터 생성된 시간을 초 단위로 기술한다.

  host_key

  • 쿠키의 도메인이다.

  name

  • 쿠키의 이름이다.

  value

  • 쿠키의 값이다.

  path

  • 쿠키와 관련된 도메인에 있는 경로다.

  expire_utc

  • 쿠키의 파기 시점이다. 초 단위로 기술한다.

  secure

  • 이 쿠키를 SSL 커넥션일 경우에만 보낼지를 가리킨다.

  httpOnly

  • 책에는 없지만 매우 중요한 값으로 사용자가 쿠키 값을 변경할 수 없도록 한다.

  마소의 인터넷 익스플로러 쿠키

• 익스플로러는 캐시 디렉터리에 각각의 개별 파일로 쿠키를 저장한다.

• 쿠키를 확인하려면 이 디렉터리를 뒤져볼 수 있다.

• 익스플로러의 쿠키 파일은 자체적인 형식을 가지고 기술되지만, 필드 대부분은 이해하기 쉽게 되어 있다.

• 각 쿠키는 개별 저장되며 각 쿠키는 여러행으로 기술된다.

  • 첫 번째 줄은 파일에 있는 각 쿠키의 이름이다.
  • 두 번째 줄은 쿠키의 값이다.
  • 세 번째 줄은 도메인 경로다.
  • 마지막 줄은 익스플로러만을 위한 데이터가 있고, 날짜나 표식같이 이 쿠키에 대한 정보들이 추가적으로 들어갈 수 있다.

  4) 사이트마다 각기 다른 쿠키들

• 브라우저는 수백 수천 개의 쿠키를 가지고 있을 수 있지만, 그렇다고 브라우저가 쿠키 전부를 모든 사이트에 보내진 않는다.

• 사실, 브라우저는 보통 각 사이트에 두 개 혹은 세 개의 쿠키만을 보낸다. 이유는 다음과 같다.

  • 쿠키를 모두 전달하면 성능이 크게 저하된다. 쿠키를 모두 전달하면 브라우저는 실제 콘텐츠의 바이트보다 많은 쿠키 바이트를 전달하게 될 것이다.
  • 이 쿠키들 대부분은 서버에 특화된 이름/값 쌍을 포함하고 있기 때문에, 대부분 사이트에서는 인식하지 않는 무의미한 값이다.
  • 모든 사이트에 쿠키 전체를 전달하는 것은, 특정 사이트에서 제공한 정보를 신뢰하지 않는 사이트에서 가져갈 수 있어서 잠재적인 개인정보 문제를
    일으킬 것이다.

• 보통 브라우저는 쿠키를 생성한 서버에게만 쿠키에 담긴 정보를 전달한다.

• 많은 웹 사이트는 광고를 관리하는 협력업체와 계약을 한다. 이 광고들은 웹 사이트 자체의 일부인 것처럼 제작되고, 지속 쿠키를 만들어낸다.

  • 같은 광고에서 제공하는 서로 다른 웹 사이트에 사용자가 방문하면, 브라우저는 앞서 만든 지속 쿠키를 다시 광고사 서버로 전송한다.
    이는 지속 쿠키의 도메인이 같기 때문이다.
  • 광고사는 이 기술에 Referer 헤더를 접목하여 사용자의 프로필과 웹 사이트를 사용하는 습관에 대한 방대한 데이터를 구축할 수 있다.
  • 최신 브라우저들은 개인정보 설정 기능을 통해 협력업체의 쿠키 사용 방식에 제약을 가할 수 있도록 하고 있다.

  쿠키의 Domain 속성

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

• 예를 들어 다음 HTTP 응답 헤더는 브라우저가 user="mary17" 이라는 쿠키를 .airtravelbargains.com 도메인을 가지고 있는 모든 사이트에
  전달한다는 의미이다.

  Set-Cookie: user="mary17"; domain="airtravelbargains.com"

• 만약 사용자가 www.airtravelbargains.com 나 special.airtravelbargains.com 같이 .airtravelbargains.com으로 끝나는
  사이트를 방문하면 다음 Cookie 헤더가 항상 적용될 것이다.

  Cookie: user="mary17"

  쿠키의 Path 속성

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

• 예를 들어 각각 쿠키를 별도로 가지는 두 개의 조직이 한 개의 웹 서버를 공유한다고 가정하자

  • www.airtravelbargains.com 사이트는 자동차를 대여하는 페이지인 http://www.airtravelbargains.com/autos/에서 사용자가
    좋아하는 자동차 크기를 기록하려 쿠키를 사용한다. 자동차 대여에 관한 쿠키는 다음과 같이 생성한다.

    Set-cookie: pref=compact; domain="airtravelbargains.com"; path=/autos/

  • 만약 사용자가 http://www.airtravelbargains.com/specials.html에 접근하면 다음 같은 쿠키만 얻게 된다.

    Cookie: user="mary17"

  • 하지만 사용자가 http://www.airtravelbargains.com/autos/cheapo/index.html로 접근하면 두 가지 쿠키를 받게 될 것이다.

    Cookie: user="mary17"
    Cookie: pref=compact

• 따라서 쿠키는 일종의 상태 정보라고 할 수 있으며, 서버가 생성하여 클라이언트에 전달하고, 클라이언트는 그 쿠키를 유효한 사이트에만 다시
  전달하고 관리한다.

  5) 쿠키 구성요소

• 현재 사용되는 쿠키 명세에는 Version 0 쿠키(흔히 넷스케이프 쿠키라 부른다.)와 Version 1 쿠키 (RFC 2965)가 있다. Version 1 쿠키
  는 Version 0 쿠키의 확장으로 널리 쓰이지는 않는다. (RFC2965는 현재 폐기 상태)

  6) Version 0 쿠키 (넷스케이프)

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

  Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure]
  Cookie: name1=value1 [; name2=value2] ...

  Version 0 Set:Cookie 헤더

• Set-Cookie 헤더는 쿠키의 이름과 값을 가져야 한다. 이는 쿠키 옵션 속성들에 세미콜론으로 이어 기술한다.

Set:Cookie 속성	설명	설정법
이름 = 값	필수 속성이며 이름과 값 모두 큰 따움표로 감싸지 않은 세미콜론, 쉼표, 등호, 공백을 포함하지 않는 문자열이다. 웹 서버는 사용자가 추후 웹 서버에 다시 방문하면 읽어올 그 어떤 이름 = 값 조합이든 만들 수 있다.	Set-Cookie: customer=Mary
Expires	선택적인 속성이며 이 속성에는 쿠키의 생명주기를 가리키는 날짜 문자열을 기술한다. 일단 파기 일자에 다다르면, 그 쿠키는 삭제될 것이며 전달되지도 않을 것이다. 사용할 수 있는 타임 존은 GMT 뿐이며 날짜 요소 간에 구분자는 대시여(-)야 한다. 쿠키에 Expires를 명시하지 않으면 그 쿠키는 사용자의 세션이 끊날 때 파기될 것이다.	Set-Cookie: foo=bar; expires=Wednesday, 09-Nov-99 23:12:40 GMT
Domain	선택적인 속성이며 브라우저는 이 속성에 기술된 도메인을 사용하는 서버 호스트 명으로만 쿠키를 전송한다. 이는 서버가 특정 도메인에만 쿠키를 제한적으로 전달하게 한다. 'acme.com' 도메인은 'anvil.acme.com'과 'shipping.crate.acme.com'의 호스트 명과는 짝지 맞지만 'www.cnn.com'과는 맞지 않다. 명시된 도메인에 해당하는 도메인들만이 쿠키를 설정할 수 있고, com, edu, va.us 같은 형식의 도메인을 기술하는 것을 방지하고자, 두 개에서 세개 영역을 가지는 도메인을 기술해야 한다. 다음과 같이 특정 최상위 단계에 있는 도메인에 해당하는 것들은 두 개의 영역만 기술하면 된다. 그 외에 도메인은 적어도 세 개의 영역을 기술해야 한다. 특정 최상위 도메인들은 다음과 같다. com, edu, net, org, gov, mil, int, biz, info, name, museum, coop, aero, pro	Set-Cookie: SHIPPING=FEDEX; domain="joes-hardware.com"
Path	선택적인 속성이며 이 속성으로 서버에 있는 특정 문서에만 쿠키를 할당할 수 있다. 만약 Path 속성에 기술된 값이 URL 경로의 앞부분과 일치하면, 쿠키를 전달한다. /foo 경로는 /foobar와 /foo/bar.html에 들어맞는다. /경로는 도메인에 있는 모든 것에 들어맞는다. 만약 경로를 명시하지 않으면, Set-Cookie 응답을 전달하는 URL의 경로가 사용된다.	Set-Cookie: lastorder=00183; path=/orders
Secure	선택적인 속성이며 이 속성이 포함되면 쿠키는 HTTP가 SSL 보안 연결을 사용할 때만 쿠키를 전송한다.	Set-Cookie: private_id=519; secure

Version 0 Cookie 헤더

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

  Cookie: session-id=002-115265-852341; session-id-time=100012312

  Version 1 쿠키 (파기된 방식으로 생략)

  8) 쿠키와 세션 추적

• 쿠키는 웹 사이트에 수차례 트랜잭션을 만들어내는 사용자를 추적하는 데 사용한다. 전자상거래 웹 사이트는 사용자가 온라인 쇼핑을 하는 중에도 그들의
  쇼핑 카트를 유지하려 세션 쿠키를 사용한다. 아마존 URI를 브라우저에 입력하면 일련의 리다이렉트, URL 리라이트, 쿠키 설정을 통해 서버가 식별
  정보를 첨부하기 위한 연속적인 트랜잭션을 시작한다.

- a: 브라우저가 아마존의 루트 페이지를 요청한다.
- b: 서버는 클라이언트를 전자상거래 소프트웨어 URL로 리다이렉트 시킨다.
- c: 클라이언트는 라다이렉트 URL로 요청 보낸다.
- d: 서버는 응답에 두 개의 세션 쿠키를 기술하고 사용자를 다른 URL로 리다이렉트 시키며, 클라이언트는 다시 이 쿠키들을 첨부하여 요청을 보낸다.
  새로운 URL은 자체에 어떤 상태 정보를 가지고 있으므로 뚱뚱한 URL 이라고 할 수 있다. 만약 클라이언트가 쿠키를 사용하지 않게 설정되어 있다면
  사용자가 아마존에서 생성한 뚱뚱한 URL 을 따라 리다이렉트 하면서도 사이트를 떠나지 않는 한, 기본 식별 절차는 계속 진행된다.
- e: 클라이언트는 새로운 URL을 요청을 앞서 받은 두개의 쿠키와 함께 보낸다.
- f: 서버는 home.html 페이지로 리다이렉트 시키고 쿠키 두 개를 더첨부한다.
- g: 클라이언트는 home.html 페지리를 가져오고 총 네 개의 쿠키를 전달한다.
- h: 서버는 콘텐츠를 보낸다.

9) 쿠키와 캐싱

• 쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 주의해야한다. 이전 사용자의 쿠키가 다른 사용자에게 할당되거나, 누군가의 개인 정보가 다른 이에게
  노출되는 상황이 일어날 수도 있다.

  캐시되지 말아야 할 문서가 있다면 표시하라
  

문서가 Set-Cookie 헤더를 제외하고 캐시를 해도 될 경우라면 그문서에 명시적으로 Cache-Control: no-cache="Set-Cookie"를 기술
또한, 캐시를 해도 되는 문서라면 Cache-Control: public을 사용하면 웹 대역폭을 절약할 수 있다.

Set-Cookie 헤더를 캐시 하는 것에 유의하라

만약 응답에 Set-Cookie 헤더를 가지고 있으면, 본문은 캐시할 수 있지만 Set-Cookie 헤더를 캐시하는 것은 주의를 기울여야 한다.
같은 Set-Cookie 헤더를 여러 사용자에게 보내면, 사용자 추적에 실패할 것이기 때문이다. 어떤 캐시는 응답을 저장하기 전에 Set-Cookie 헤더를
제거하기 때문에, 그 캐시 데이터를 받는 클라이언트는 문제가 발생할 수 있다. 캐시가 모든 요청마다 원 서버와 재검사시켜 클라이언트로 가는
응답에 Set-Cookie 헤더 값을 기술해서 이 문제를 개선할 수 있다. Cache-Control: must-revalidate, max-age=0

Cookie 헤더를 가지고 있는 요청을 주의하라

요청이 Cookie 헤더와 함께 오면, 결과 콘텐츠가 개인정보를 담고 있을 수도 있다는 힌트다. 개인정보는 캐시되지 않도록 표시되어야 하지만, 그 표시를
하지 않는 서버도 있다.

  <Strong>10) 쿠키, 보안 그리고 개인정보
  - 쿠키는 사용하지 않도록 비활성화시킬 수 있고, 로그 분석 같은 다른 방벅으로 대체 가능하므로 보안상 엄청 위험하진 않다.
  - DB에 개인 정보를 저장하고 해당 데이터의 키 값을 쿠키에 저장하는 방식을 표준으로 하용하면 예민한 데이터를 오가는 것을 줄일 수 있다.
  - 개인정보나 사용자 추적하는 기술은 잘못된 의도로 사용될 수 있기에 항상 조심하는 것이 좋다.
  - 가장 큰 오용은 협력업체 웹 사이트가 사용자를 추적하려고 지속 쿠키를 사용하는 것이다.
    - 이것을 IP 주소와 Referer 헤더에 있는 정보와 함께 사용하면, 마케팅 회사들은 사용자의 프로필과 사용 패턴에 대해 정확한 데이터 수집이 
      가능하다.
  - 쿠키는 부정적인 여론이 많지만 제공하는 개인정보를 누가 받는지 명확히 알고 사이트의 개인정보 정책에만 유의하면 편리함이 더 크다.

미국 재무성 컴퓨터 사고 자문단 : 인터넷 쿠키

문제 : 쿠키는 웹 서버가 웹 사용자를 식별하는 작은 데이터 조각이다. 쿠키의 개념과 기능에 대해 이해할 수 없는 수준까지 올라온 수많은
뜬소문들은 사용자를 놀라게 하고 그들의 관리자까지 걱정 끼칠 수준이다.

취약성 평가 : 쿠키를 사용하면 시스템의 추약한 부분이 손상되거나 스누핑 하는 것은 근복적으로 있을 수 없다.
쿠키는 당신의 방문 흔적과 약간의 정보(사용자 번호와 같은)를 다시 접속 하였을 때 서버에게 다시 보내는 용도일 뿐이다.
쿠키는 대부분 세션 쿠키이며 지속 쿠키 또한 파기 시간을 가지고 있고 시간이 지나면 디스크에서 삭제된다.
지속 쿠키는 사용자가 언제 사이트로 돌아오는지 식별해서 사용자의 탐색 습관을 추적하는데 사용될 수 있다.
당신이 어디서 왔는지, 당신이 어떤 페이지에 접근했는지 로그파일도 존재하며, 그것을 통해서 사용자의 브라우징 습관을 추적할 수도 있다.
쿠키는 그것을 좀 더 편리하게 해줄 뿐이다.
```