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

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

 

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

• 이 장에서는 서버가 통신하는 대상을 식별하는 데 사용하는 기술을 알아본다.

1. 개별 접촉

• HTTP 는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 프로토콜이다.
• 현대의 웹 사이트들은 개인화된 서비스를 제공하고 싶어 한다.
• Amazon.com 같이 유명한 온라인 쇼핑 사이트는 여러 가지 방식으로 사이트를 개인화시켜서 사용자에게 제공한다.
• 개별인사
  • 온라인 쇼핑이 개인에게 맞춰져 있는 것처럼 느끼게 하려고 사용자에게 특화된 환영 메시지나 페이지 내용을 만든다.
• 사용자 맞춤 추천
• 저장된 사용자 정보
  • 예)사용자 주소나 신용카드 계좌를 사용자가 매번 입력하지 않게 하기 위해 데이터 베이스에 저장하는 온라인 상점
• 세션 추적
  • HTTP 트랜잭션은 상태가 없다. 각 요청 및 응답은 독립적으로 일어난다.
  • 많은 웹 사이트에서 사용자가 사이트와 상호작용할 수 있게 사용자의 상태를 남긴다.(예 장바구니)
  • 각 사용자에게서 오는 HTTP 트랜잭션을 식별할 방법이 필요하다.

2. HTTP 헤더

• 사용자에 대한 정보를 전달하는 가장 일반적인 일곱 가지 HTTP 헤더에 대해 알아보겠다.

1. From 헤더는 사용자의 이메일 주소를 포함한다.
   • 하지만 이는 스펨 메시지 보내는 등의 악의적인 서버가 이메일 주소를 모으는 등의 문제가 있어서 사용을 많이 하지 않는다.
2. User-Agent 헤더는 사용자가 쓰고 있는 브라우저의 이름과 버전 정보, 어떤 경우에는 운영체제에 대한 정보까지 포함하여 서버에게 알려준다.
   • 사용자를 식별하는데에는 도움이 안됨
   • 특정 브라우저에 대한 기능 구현할 때는 쓰임
3. Referer 헤더
   • 사용자가 이 페이지에 유입하게 된 이전 페이지의 URL 을 나타낸다.
   • 이는 사용자의 이전에 어떤 페이지인지 알려주고 사용자의 취향을 알 수 있다.

• 위 3개의 헤더들은 사용자를 식별하기에는 부족한 정보를 가진다.

3. 클라이언트 IP 주소

• 초기 웹은 사용자 식별에 클라이언트 IP 주소를 사용하려 했다.
  • 이유는 IP 주소는 자주 바뀌지 않기 때문이었다.
• 알아내는 방법은 TCP 커넥션의 특성중 요청을 보내는 쪽의 IP 주소를 알 수 있다.
• 하지만 이는 약점이 존재한다.
  • 만약 여러 사용자가 같은 컴퓨터를 사용해 IP를 공유하는 경우
  • 클라이언트와 서버 사이에 프락시가 있어서 프락시 의 IP 주소를 가지는 경우
  • 방화벽에 실제 IP 주소가 가려지는 경우
• 제한된 영역에서는 적절할 수 있지만, 인터넷에서는 IP 주소를 임의로 변경할 수 있기 때문에 문제가 발생할 수 있다

4. 사용자 로그인

• IP 주소로 사용자를 식별하는 수동적인 방법보다 사용자 로그인 할 것을 요구해서 사용자에게 명시적으로 식별 요청을 할 수 있다.
• 웹 사이트 로그인이 더 쉽도록 HTTP 는 WWW-Authenticate와 Authorization 헤더를 사용해 웹 사이트에 사용자 이름을 전달하는 자체적인 체계를 가지고 있다.
• 한번 로그인하면, 브라우저는 사이트로 보내는 모든 요청에 이 로그인 정보를 함께 보내므로 웹 서버는 그 로그인 정보는 항상 확인할 수 있다.

• 하지만 로그인으로 사용자를 식별한다면 다른 사이트를 방문할 때마다 로그인을 해야하고 모든 사이트의 로그인 정보를 암기해야한다는 단점이 있을 것이다.

5. 뚱뚱한 URL

• 어떤 웹 사이트는 사용자의 URL마다 버전을 기술하여 사용자를 식별하고 추적하였다.
• 보통, URL 경로의 처음이나 끝에 어떤 상태 정보를 추가해 확장한다.
  • 이런 URL을 뚱뚱한 URL이라고 한다.
• 독립적인 HTTP 트랜잭션을 하나의 세션 혹은 방문으로 묶는 용도로 뚱뚱한 URL을 사용할 수 있다.
• 하지만 이 기술은 심각한 문제가 있다.
  • 못생긴 URL ( 너무 과도하게 길어진 URL은 사용자의 혼란을 야기한다.
• 공유하지 못하는 URL
  • 사용자의 상태 정보를 가지고 있으므로 URL을 공유하는게 쉽지 않다.
• 캐시를 사용할 수 없음
  • URL이 달라지기 때문에 기존 캐시에 접근 할 수 없다.
• 서버 부하 가중
• 이탈
  • 사용자가 링크를 타고 다른 사이트로 이동하거나 특정 URL 을 요청해서 의도치 않게 뚱뚱한 URL 세션에서 이탈하기 쉽다.
• 세션 간 지속성의 부재
  • URL 을 북마킹하지 않는 이상 로그아웃하면 모든 정보를 잃는다.

6. 쿠키

• 쿠키는 사용자를 식별하고 세션을 유지하는 방식 중에서 현재까지 널리 사용하는 방식이다.
• 쿠키는 위 방식의 문제는 가지지 않지만 쿠키만으로 하기 힘든 일에는 앞서 설명한 기술들을 함께 사용하기도 한다.
• 쿠키는 캐시와 충돌할 수 있어서, 대부분의 캐시나 브라우저는 쿠키에 있는 내용물을 캐싱하지 않는다.

6.1. 쿠키의 타입

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

6.2 쿠키는 어떻게 동작하는가

• 처음에 사용자가 웹 사이트에 방문하면 웹 서버는 사용자에 대해서 아무것도 모른다.
• 웹 서버는 사용자가 다시 돌아왔을 때 , 해당 사용자를 식별하기 위한 유일한 값을 쿠키에 할당한다.
• 쿠키는 임의의 이름=값 형태의 리스트를 가지고, 그 리스트는 set-cookie 혹은 set-cookie2 같은 HTTP 응답 헤더에 기술되어 사용자에게 전달한다.
  • 쿠키는 어떤 정보든 포함할 수 있지만, 서버가 사용자 추적 용도로 생성한 유일한 단순 식별번호만 포함하기도 한다.
  • 이 식별번호는 나중에 브라우저가 쿠키를 보내면 사용자의 정보를 데이터베이스에서 찾을 때 사용되곤 한다.
• 브라우저는 서버로 온 Set-Cookie 혹은 Set-Cookie2 헤더에 있는 쿠키 콘텐츠를 브라우저 쿠키 데이터 베이스에 저장한다.
  • 나중에 같은 사이트를 방문하면 쿠키 데이터 베이스에 저장한 쿠키를 보낸다.

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

• 브라우저는 쿠키 정보를 저장할 책임이 있다. 이 시스템을 클라이언트 측 상태라고 한다.
  • 공식적인 이름은 HTTP 상태 관리 체계라고 한다.
• 구글 크롬 쿠키

- 구글 크롬은 Cookies라는 SQLite라는 파일에 쿠키를 저장한다.
- 각 행이 쿠키 한개의 해당
- 필드 의미는 다음과 같다.

    **creation_utc**

    쿠키가 생성된 시점을 초 단위로 기술

    **host_key**

    쿠키의 도메인

    **name**

    쿠키의 이름

    **value** 쿠키의 값

    **path**

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

    **expires_utc**

    쿠키의 파기 시점을 초 단위로 기술

    **is_secure**

    이 쿠키를 SSL 커넥션일 경우에만 보낼지 여부

6.4 사이트마다 각기 다른 쿠키들

• 브라우저는 수백 수천 개의 쿠키를 가질 수 있지만, 쿠키 전부를 모든 사이트에 보내지 않는다.
• 보통 각 사이트에 2~3개의 쿠키만을 보낸다.
  • 쿠키를 모두 전달하면 성능이 크게 저하. 모두 전달하면 브라우저는 실제 콘텐츠의 바이트보다
  • 더 많은 쿠키 바이트를 전달하게 된다.
  • 쿠키 대부분 서버에 특화된 name/value 쌍을 포함하기 때문에, 대부분의 사이트에서는 무의미한 값이다.
  • 특정 사이트에서 제공한 정보를 신뢰하지 않는 사이트에서 가져갈 수 있어서 보안에 문제를 일으킬 수 있다.
• 브라우저는 쿠키를 생성한 서버에게만 쿠키에 담긴 정보를 전달한다.

쿠키 Domain 속성

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

Set-cookie: user="rowanlee92"; domain="github.com"

예를 들어 사용자가 www.github.com, www.test.github.com 처럼 .github.com으로 끝나는 사이트를 방문하면 Cookie 헤더가 항상 적용된다.

Cookie: user="rowanlee92"

쿠키 Path 속성

URL 경로의 앞부분을 가리키는 Path 속성을 기술해서 해당 경로에 속하는 페이지에만 쿠키를 전달할 수 있다.

Set-cookie: pref=compact; domain="github.com"; path=/pro/

www.github.com으로 접근하면

Cookie: user="rowanlee92"

쿠키 한 개를 얻을 수 있고

www.github.com/pro/로 접근하면

Cookie: user="rowanlee92"
Cookie: pref=compact

두 가지 쿠키를 얻는다.

따라서, 쿠키는 일종의 상태정보 라고 할 수 있다.

6.5 쿠키 구성요소

• 쿠키 버전
  • Version 0 쿠키 ( 넷스케이프 쿠키라고 불린다.)
  • Version 1 쿠키 ( Version 0 쿠키의 확장)

6.6 Version 0 쿠키

Set-Cookie 헤더

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

아래의 표는 Set-Cookie 필드 정보이다.

Set-Cookie 속성	설명 및 용례
이름=값	(필수) 큰 따옴표로 감싸지 않고 세미콜론, 쉼표, 등호, 공백을 포함하지 않는 문자열
Expires	(선택) 쿠키의 생명주기를 가리키는 날짜 문자열. 사용할 수 있는 타임존은 GMT. Expires가 없다면 세션쿠키
Domain	(선택) 이 속성에 기술된 도메인을 사용하는 서버로만 쿠키를 전송. 도메인 명시되어있지 않으면, Set-Cookie 응답을 생성한 서버의 호스트 명이 기본값으로 사용됨
Path	(선택) 서버에 있는 특정 경로만 쿠키를 할당. 경로가 명시되어있지 않으면, Set-Cookie 응답을 전달하는 URL의 경로가 사용됨
Secure	(선택) 이 속성이 포함되면, 쿠키는 HTTP가 SSL 보안 연결 사용할 때만 전달
- 클라이언트가 서버에 요청을 보낼 때는 , Domain ,Path, Secure 필커들이 현재 요청하려고 하는 사이트에 들어맞으면서 아직 파기되지 않는 쿠키들을 함께 보낸다.

6.8 쿠키와 세션 추적

• 브라우저가 Amazon.com 루트 페이지를 요청
• 서버는 클라이언트를 전자상거래 소프트웨어 URL로 리다이렉트
• 클라이언트는 리다이렉트 URL로 요청
• 서버는 응답에 두 개의 세션 쿠키를 기술 후, 사용자를 다른 URL로 리다이렉트.
• 클라이언트는 앞에 받은 두 개의 쿠키와 함께 새로운 URL로 요청
• 서버는 home.html 페이지로 리다이렉트 시키고 쿠키 두 개를 추가적으로 첨부
• 클라이언트는 home.html 페이지를 요청하고 총 4개의 쿠키를 전달
• 서버는 콘텐츠를 보낸다.

6.9 쿠키와 캐싱

• 쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 주의해야 한다.
• 이전 사용자의 쿠키가 다른 사용자에게 할당돼버리거나, 누군가의 개인정보가 다른 이에게 노출되는 최악의 상황이 일어날 수도 있다.
• 쿠키와 캐싱에 관련된 규칙은 정리가 잘되어 있지 않다. 다음은 캐시를 다루는 기본 원칙에 대한 안내이다.

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

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

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

캐시가 모든 요청마다 원 서버와 재검사시켜 클라이언트로 가는 응답에 Set-Cookie 헤더 값을 기술할 수 있도록 원 서버는 다음의 헤더를 캐시 문서에 추가한다.

Cache-Control: must-revalidate, max-age=0

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

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

Set-Cookie가 있는 이미지에 대해서는 캐시를 하지만, 텍스트는 캐시를 하지 않는 캐시도 있다. 따라서, 캐시 이미지에 파기 시간이 0인 Cookie 헤더를 설정해서 매번 재검사를 하도록 강제한다.

6.10 쿠키 , 보안 그리고 개인정보

• 쿠키를 사용하지 않도록 비활성화시킬 수 있고, 로그 분석 같은 다른 방법으로 대체하는 것도 가능하므로, 그 자체가 보안상으로 엄청나게 위험한 것은 아니다.
• 해당 데이터를 쿠키에 저장하는 방식을 표준으로 사용하면 , 예민한 데이터가 오가는 것을 줄일 수 있다.
• 하지만 개인정보를 오고감은 항상 조심하는 것이 좋다.