클라이언트 식별과 쿠키

 웹 서버는 서로 다른 수천 개의 클라이언트들과 동시에 통신한다. 이 서버들은 익명의 클라이언트로부터 받는 모든 요청을 처리하는 것뿐만 아니라 서버와 통신하고 있는 클라이언트를 추적해야 할 수도 있다. 

 

 HTTP는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 프로토콜이다. 웹 서버는 요청을 보낸 사용자를 식별하거나 방문자가 보낸 연속적인 요청을 추적하기 위해 약간의 정보를 이용할 수 있다.

 

개별 인사

온라인 쇼핑이 개인에게 맞춰져 있는 것처럼 느끼게 하려고 사용자에게 특화된 환영 메시지나 페이지 내용을 만든다.

 

사용자 맞춤 추천

온라인 상점은 고객의 흥미가 무엇인지 학습해서 고객이 좋아할 것이라고 예상되는 제품들을 추천할 수 있다. 고객의 생일이나 다른 중요한 날이 다가오면 특별한 제품을 제시하기도 한다.

 

저장된 사용자 정보

온라인 쇼핑 고객은 복잡한 주소와 신용카드 정보를 매번 입력한느 것을 싫어한다. 이런 정보를 데이터베이스에 저장하는 온라인 상점도 있다. 온라인 쇼핑이 당신을 한번 식별하고 나면, 쇼핑을 더 편하게 할 수 있게 저장된 사용자 정보를 사용할 수 있다.

 

세션 추적

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

 

사용자 식별 기술에는 다음과 같은 것이 있다.

 

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

 

 

HTTP 헤더

 

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

 

위 표는 사용자에 대한 정보를 저장하는 가장 일반적인 일곱 가지 HTTP 요청 헤더가 기술되어 있다. 

 

 

클라이언트 IP 주소

 웹 서버는 HTTP 요청을 보내는 반대쪽 TCP 커넥션의 IP 주소를 알아낼 수 있다. 하지만 클라이언트 IP 주소로 사용자를 식별하는 방식은 다음과 같은 약점을 갖는다.

• 클라이언트 IP 주소는 사용자가 아닌, 사용하는 컴퓨터를 가리킨다. 만약 여러 사용자가 같은 컴퓨터를 사용한다면 그들을 식별할 수 없다.
• 많은 인터넷 서비스 제공자(ISP)는 사용자가 로그인하면 동적으로 IP 주소를 할당한다. 로그인한 시단에 따라, 사용자는 매번 다른 주소를 받으므로, 웹 서버는 사용자를 IP 주소로 식별할 수 없다.
• 보안을 강화하고 부족한 주소들을 관리하려고 많은 사용자가 네트워크 주소 변환(Network Address Translation, NAT) 방화벽을 통해 인터넷을 사용한다. 이 NAT 장비들은 클라이언트의 실제 IP 주소를 방화벽 뒤로 숨기고, 클라이언트의 실제 IP 주소를 내부에서 사용하는 하나의 방화벽 IP 주소로 변환한다.
• HTTP 프락시와 게이트웨이는 원 서버에 새로운 TCP 연결을 한다. 웹 서버는 클라이언트의 IP 주소 대신 프락시 서버의 IP 주소를 본다. 

 

사용자 로그인

 IP 주소로 사용자를 식별하려는 수동적인 방식보다, 웹 서버는 사용자 이름과 비밀번호로 인증(로그인)할 것을 요구해서 사용자에게 명시적으로 식별 요청을 할 수 있다.

 웹 사이트 로그인이 더 쉽도록 HTTP는 WWW-Autenticate 와 Authorication 헤더를 사용해 웹 사이트에 사용자 이름을 전달하는 자체적인 체계를 가지고 있다. 한번 로그인하면, 브라우저는 사이트로 보내는 모든 요청에 이 로그인 정보를 함께 보내므로 웹 서버는 그 로그인 정보는 항상 확인할 수 있다. 

HTTP 인증 헤더를 이용한 사용자 등록

 

 

뚱뚱한 URL

 어떤 웹 사이트는 사용자의 URL 마다 버전을 기술하여 사용자를 식별하고 추적하였다. 보통, URL은 URL 경로의 처음이나 끝에 어떤 상태 정보를 추가해 확장한다. 사용자가 그 사이트를 돌아다니면, 웹 서버는 URL에 있는 상태 정보를 유지하는 하이퍼링크를 동적으로 생성한다.

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

뚱뚱한 URL 예시

 

 

하지만 이 기술에는 여러 문제가 있다.

 

못생긴 URL

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

 

공유하지 못하는 URL

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

 

캐시를 사용할 수 없음

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

 

서버 부하 가중

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

 

이탈

사용자가 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청해서 의도치 않게 뚱뚱한 URL 세션에서 '이탈'하기 쉽다. 사용자는 서비스를 사용하는 동안, 사전에 세션 정보가 추가된 링크만을 사용해야 뚱뚱한 URL이 문제없이 동작할 수 있다.

 

세션 간 지속성의 부재

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

 

 

쿠키

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

 

쿠키의 타입

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

 

세션 쿠키와 지속 쿠키의 다른 점은 파기되는 시점뿐이다.

 

쿠키는 어떻게 동작하는가

 쿠키는 서버가 사용자에게 "안녕, 내 이름은.."라고 적어서 붙이는 스티커와 같다. 사용자가 웹 사이트에 방문하면, 웹 사이트는 서버가 사용자에게 붙인 모든 스티커를 읽을 수 있다.

  

 웹 서버는 사용자가 다시 돌아왔을 때, 해당 사용자를 식별하기 위한 유일한 값을 쿠키에 할당한다. 쿠키는 임의의 이름=값 형태의 리스트를 가지고, 그 리스트는 Set-Cookie 혹은 Set-Cookie2(확장 헤더) 같은 HTTP 응답 헤더에 기술되어 사용자에게 전달한다.

 

 쿠키는 어떤 정보든 포함할 수 있지만, 서버가 사용자 추적 용도로 생성한 유일한 단순 식별 번호만 포함하기도 한다.

 

 

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

쿠키의 기본적인 발상은 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때마다 그 정보를  함께 전송하게 하는 것이다. 브라우저는 쿠키 정보를 저장할 책임이 있는데, 이 시스템을 '클라이언트 측 상태'라고 한다.

사용자에게 쿠키 할당

 

 

구글 크롬 쿠키

구글 크롬은 Cookies 라는 SQLite 파일에 쿠키를 저장한다.

 

이 SQLite 파일에 있는 각 행이 쿠키 한 개에 해당한다.

 

creation_utc

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

 

host_key

쿠키의 도메인이다.

 

name 

쿠키의 이름이다.

 

value

쿠키의 값이다.

 

path

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

 

expire_utc

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

 

secure

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

 

 

쿠키와 캐싱

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

• 캐시되지 말아야 할 문서가 있다면 표시하라
• Set-Cookie 헤더를 캐시 하는 것에 유의하라 (같은 Set-Cookie 헤더를 여러 사용자에게 보내면, 사용자 추적에 실패한다.)
• Cookie 헤더를 가지고 있는 요청을 주의하라

 

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

 쿠키를 사용하지 않도록 비활성화시킬 수 있고, 로그 분석 같은 다른 방법으로 대체하는 것도 가능하므로, 그 자체가 보안상으로 엄청나게 위험한 것은 아니다. 사실, 원격 데이터베이스에 개인 정보를 저장하고 해당 데이터의 키 값을 쿠키에 저장하는 방식을 표준으로 사용하면, 클라이언트와 서버 사이에 예민한 데이터가 오가는 것을 줄일 수 있다.