클라이언트 식별과 쿠키

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

개별 접촉

HTTP는 익명으로 사용하며 상태가 없고 요청(Request)과 응답(Response)로 통신하는 프로토콜

현대의 웹 사이트들은 개인화된 서비스들을 제공하고 싶어한다.

개별 인사

개인에게 맞춰져 있는 것처럼 느끼게 하려고 사용자에게 특화된 환영 메세지나 페이지 내용을 만듦

사용자 맞춤 추천

고객의 흥미가 무엇인지 학습해서 고객이 좋아할 만한 상품을 추천해준다.

개개인의 기념일이나 생일이 다가오면 그에 맞는 상품을 제시할 수도 있다.

저장된 사용자 정보

배송지 주소와 카드 정보를 매번 입력받게 하지말고

데이터베이스에 저장하여 저장하는 경우를 말한다.

세션 추적

HTTP 트랜잭션은 상태가 없다.

각 요청, 응답은 독립적으로 일어난다.

사용자가 사이트와 상호작용 할 수 있게 사용자의 상태를 남기는데,

여러 상태들을 유지하려면, 웹 사이트는 HTTP 트랜잭션을 식별할 방법이 필요하다.

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

HTTP 헤더

헤더 이름	헤더 타입	설명
From	요청	사용자의 이메일 주소
User-Agent	요청	사용자의 브라우저
Referer	요청	사용자가 현재 링크를 타고 온 근원 페이지

From 헤더

사용자의 이메일 주소를 포함

고유한 이메일 주소를 갖기 때문에 이론상 From헤더로 사용자를 식별할 수 있다.

악의적 서버가 이 이메일 주소들을 모아 스팸메일을 발송할 수 있는 문제가 있다.

로봇이나 스파이더는 본의 아니게 웹 사이트에 문제를 일으킨 경우, 항의 메일을 보낼 수 있도록

From헤더에 이메일 주소를 기술한다고 함

User-Agent 헤더

사용자가 쓰고 있는 브라우저의 이름과 버전정보, 등등을 서버에게 알려준다.

이는 특정 브라우저에게 특화된 컨텐츠를 최적화하는데 도움을 줄 수 있지만,

특정 사용자들을 식별하는 데는 큰 도움이 되지 않는다.

• 헤더 예시

Referer 헤더

사용자가 현재 페이지로 유입하게 한 웹페이지의 URL을 가리킨다.

이 헤더로 이전에 어떤 페이지를 방문했었는지 알 수 있다.

왜? - 여기까지 들어오기 직전의 URL을 파악할 수 있기 때문에 유추할 수 있게 된다.

---

하지만 이 세가지 헤더로 확실하게 뭔가를 식별하기엔 정보가 부족함.

클라이언트 IP 주소

사용자가 확실한 IP 주소를 가지고 있고, 그 주소가 바뀌지 않고, 웹 서버가 요청마다

클라이언트 IP를 알 수 있다면 문제없이 동작한다.

약점

클라이언트 IP 주소는 사용자가 아닌, 사용하는 컴퓨터를 가리킴.

여러 사람이 이용하는 경우 그들을 식별할 수 없다.

인터넷 서비스 제공자는 동적으로 IP주소를 할당

그렇기 때문에 사용자를 IP 주소로 식별할 수 없음

보안을 강화하고 부족한 주소들을 관리하려고 NAT 방화벽을 통해 인터넷을 사용함.

클라이언트의 실제 IP 주소를 방화벽 뒤로 숨기기 때문에 식별할 수 없음

HTTP 프락시와 게이트웨이는 원서버에 새로운 TCP 연결

이렇게 되면 실제 IP주소가 아닌 프락시의 IP주소를 보게 됨

사용자 로그인

IP 주소로 식별하는 수동적 방식보다,

웹 서버는 사용자 이름과 비밀번호 인증을 요구하여 명시적으로 식별할수 있다.

WWW-Authenticate, Authorization 헤더를 사용하여 사용자 이름을 전달하는 체계를 갖고 있음.

자세한 내용은 12장에서 다룰 예정

뚱뚱한 URL

어떤 웹 사이트는 사용자의 URL마다 버전을 기술하여 사용자를 식별하고 추적했다.

뚱뚱한 URL이란?

사용자의 상태 정보를 포함하고 있는 URL

사용자와 관련된 정보를 찾아서 밖으로 향하는 모든 하이퍼링크에 정보를 포함하기 때문에

뚱뚱한 URL이 되고,

이 뚱뚱한 URL은 심각한 문제들이 있다.

못생긴 URL

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

공유하지 못하는 URL

당연한 얘기인것은, 이 뚱뚱한 URL에 사용자에 관련된 정보들이 포함되어 있다.

그렇기에 공유하는 순간 내 개인정보들도 같이 공유한다는 것이 된다.

캐시를 사용할수 없음

URL로 만드는 것은, 계속해서 요청되는 URL이 변경되기 때문에 기존 캐시에 접근할 수 없다.

서버 부하 가중

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

이탈

URL에 정보들이 추가된것만 사용해야 문제없이 동작한다.

하지만 중간에 사용자가 이탈하게 되면, 진행상황들이 다 리셋이 되는 경우가 발생할 것이다.

세션 간 지속성의 부재

특정 URL을 저장해놓지 않는 이상은, 로그아웃하게 되면 정보를 전부 잃는것이 된다.

쿠키

쿠키는 사용자를 식별하고 세션을 유지하는 방식 중, 현재 가장 널리 사용하는 방식

쿠키는 넷스케이프에서 개발했지만, 지금은 모든 브라우저에서 지원한다.

쿠키는 캐시와 충돌할 수 있어서, 대부분의 캐시나 브라우저는 쿠키에 있는 내용물을

캐싱하지 않는다.

쿠키의 타입

쿠키는 세션쿠키, 지속쿠키 두가지 타입이 존재

세션 쿠키 - 사용자가 브라우저를 닫으면 삭제되는 쿠키

지속 쿠키 - 삭제되지 않고 더 길게 유지될 수 있는 쿠키

두개의 차이점은 파기되는 시점

파기까지 남은 시간인 Expires 또는 Max-Age 파라미터가 없다면 세션 쿠기가 된다.

쿠키 동작

사용자가 웹 사이트에 방문하면, 웹사이트는 서버가 사용자에게 할당한 값들을 모두 읽을 수 있다.

쿠키는 임의의 이름=값 형태의 리스트를 가지고, Set-Cookie or Set-Cookie2(확장 헤더)와 같은 HTTP 응답 헤더에 기술되어

사용자에게 전달 된다.

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

쿠키의 기본은 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때 마다

그 정보를 함께 전송하게 하는 것

브라우저가 쿠키 정보를 저장할 책임이 있는데 이게 클라이언트 측 상태 = HTTP 상태 관리 체계

구글 크롬 쿠키

각 사이트마다 다른 쿠키

브라우저는 수백 수천 개의 쿠키를 가지고 있을 수는 있지만,

브라우저가 쿠키 전부를 모든 사이트에 보내지는 않는다.

1. 모두 전달하면 성능이 크케 저하
2. 특정 서버에 특화된 이름=값 쌍을 포함하기 때문에 인식하지 않는 무의미한 값 존재
3. 특정 사이트에서 제공된 정보를 다른 사이트에서 가져갈 수 있어 개인적인 정보 문제 존재

쿠키 도메인 속성

Set-cookie: user="lsj8367"; domain="sprout.or.kr"

sprout.or.kr 도메인에 user="lsj8367"을 전달한다라는 의미

쿠키 Path 속성

Path 속성으로 해당 경로쪽에 속하는 페이지만 쿠키를 전달하게 하는 속성

Version 0 쿠키

넷스케이프 쿠키

Set-Cookie 속성

• 이름=값
  • 필수 속성
  • 이름, 값 둘다 큰따옴표로 감싸지 않은, ;, ,, =, 공백 을 포함하지 않는 문자열
• Expires
  • 선택적 속성
  • 쿠키의 생명주기를 가리키는 날짜 문자열
  • 이 일자에 다다르면 그 쿠키는 삭제됨
  • 사용할 수 있는 타임 존 = GMT
    • 형식 : 요일, DD-MM-YY HH:MM:SS GMT
  • 명시하지 않으면 사용자 세션이 끝날 때 파기
• Domain
  • 선택적 속성
  • 속성에 기술된 도메인을 사용하는 호스트만 쿠키를 전송
  • 명시되어 있지 않다면, Set-Cookie 응답을 생성한 서버의 호스트명을 사용
• Path
  • 선택적 속성
  • 서버에 있는 특정 URL만 쿠키 할당
  • 경로를 명시하지 않으면, Set-Cookie 응답을 전달하는 URL의 경로 사용
• Secure
  • HTTP가 SSL 보안 연결을 사용할 때만 쿠키 전송

Version 1 쿠키

Set-Cookie2 속성

• 이름=값
  • 필수 속성
  • $ 는 예약된 문자이므로 쿠키 이름은 $로 시작하면 안된다.
• Version
  • 필수 속성
  • 쿠키 명세 버전을 가리키는 정수 값
• Comment
  • 선택적 속성
  • 서버가 쿠키를 사용하려는 의도 기술
  • 인코딩 반드시 UTF-8
• CommentURL
  • 선택적 속성
  • 쿠키 사용 목적과 정책에 대해 상세하게 기술된 URL 링크 제공
• Discard
  • 선택적 속성
  • 이 속성이 있다면, 클라이언트 프로그램 종료될 때 클라이언트가 해당 쿠키를 삭제
• Domain
  • 선택적 속성
  • 기술된 도메인에 해당하는 서버 호스트들에게만 쿠키 전송
• Max-Age
  • 선택적 속성
  • 쿠키 생명주기 초 단위
  • 클라이언트는 HTTP/1.1 수명 계산 규칙에 따라 수명을 계산해야 한다
• Path
  • 선택적 속성
  • 서버에 있는 특정 문서에만 쿠키 할당
  • Version 0 과 동일
• Port
  • 선택적 속성
  • 값 없이 속성의 키워드만 기술할 수 있고, 포트를 한개 이상 콤마를 이용하여 구분 기술할 수 있음
• Secure
  • HTTP가 SSL 보안 연결을 사용할 때만 쿠키가 전송

쿠키와 세션 추적

쿠키는 웹 사이트에 수차례 트랜잭션을 만들어내는 사용자를 추적하는데 사용한다.

쿠키와 캐싱

쿠키 트랜잭션과 관련된 문서를 캐싱하는 것을 주의해야 한다.

이유?

이전 사용자의 쿠키가 다른 사용자에게 할당되거나, 개인정보까지도 노출이 될 수 있다.

캐시를 다루는 기본 원칙

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

문서가 Set-Cookie 헤더를 제외하고 캐시해도 되는 경우라면,

그 문서에 명시적으로 Cache-Control: no-cache="Set-Cookie" 를 기술하여 명확히 표시한다.

캐시를 해도 되는 문서에 Cache-Control: public 을 사용하면 웹의 대역폭을 더 절약시켜준다.

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

같은 Set-Cookie 헤더를 여러 사용자에게 보내게 되면, 사용자 추적에 실패할 것

어떤 캐시는 Set-Cookie 헤더를 응답 저장전에 제거한다.

이런 문제를 방지하기 위해서 모든 요청마다 캐시가 원 서버와 재검사를 시켜 Set-Cookie 헤더 값을 주어

이 문제를 개선할 수 있다.

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

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

요청에 Cookie 헤더와 같이 넘겨지면, 결과가 개인정보를 담고 있을 수 있다.

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

쿠키를 사용하지 않도록 비활성화도 가능하기 때문에, 이 자체가 보안상으로 위험하다고 할수는 없다.

개인정보를 다루거나 사용자를 추적하는 기술은 잘못된 의도로 사용할 수 있기 때문에 주의하여야 한다.

가장 큰 오용중 하나는 사용자 추적을 위한 지속 쿠키이다.

개인 정보를 누가 받는지 명확하게 파악하고, 개인정보 정책을 유의한다면

위험성 보다는 세션 조작이나 트랜잭션상 편리함이 크다.