08. 쿠키

 

우리가 많이 찾는 인터넷 쇼핑몰에서는 내가 자주 산 물건이라고 하며, 상품 추천 칸이 따로 있습니다. 또 결제를 할 때도, 사용자만 인증을 한다면, 즉시 저장된 결제 정보를 가지고 결제를 할 수 있습니다.

유튜브에서는 로그인한 계정에 따라 개인 추천 동영상이 달라집니다!

이렇게 그 사용자에 맞는 정보를 제공하는 것은 아주 중요합니다. 

 

사용자 정보와 식별

정보를 제공하기 앞서 이 사용자가 누구인지에 대한 식별이 필요합니다! 사용자 정보는 어디서 가져오고, 또 어떻게 식별을 하는지 알아봅시다.

사용자 정보를 가지는 HTTP 헤더

컴퓨터들은 7가지의 HTTP 헤더로 사용자 정보를 주고받습니다. 이 정보들을 통해, 이 사용자가 누구인지 접근 권한이 있는지, 또 어떤 데이터를 찾는 경향이 있는지를 알 수 있습니다.

헤더 명	설명
FROM	사용자의 이메일 주소 요청
User-Agent	사용자의 브라우저 정보 (이름, 버전, 운영체제, 등) 요청 =>브라우저 최적화
Referer	이전 페이지 URL 요청(어느 웹사이트에서 방문했는가?) => 사용자의 취향 파악
Authorization	사용자 이름(ID), 비밀번호 요청
Client-IP	클라이언트의 IP 주소
X-Forwarded-For	클라이언트의 IP 주소
Cookie	서버가 생성한 ID 라벨 (쿠키)

 

사용자 식별

이제 이 정보들을 토대로 사용자를 식별할 차례입니다. 클라이언트 IP 주소를 통한 식별과, 사용자 로그인을 통한 식별 두 방법이 있습니다.

 

1. 클라이언트 IP 주소를 통한 식별

초창기에는 클라이언트 IP 주소를 이용해 사용자를 식별하고자 했습니다. 하지만 몇몇 문제점이 있습니다.

 

1) 클라이언트 IP는 사용자를 특정할 수 없다.

개인용 컴퓨터를 사용중라면 문제없지만, 공용 컴퓨터일 경우에는 사용자가 특정화되지 않을뿐더러, 개인정보 침해의 여지도 생깁니다.

또한 인터넷 서비스 제공자(ISP)가 발달하며 IP를 동적으로 할당하는데, 이 또한 사용자를 특정할 수 없는 요인이 됩니다. 

 

2) 보안을 위해 네트워크 주소변환(NAT) 방화벽을 통해 인터넷을 이용한다.

방화벽을 통과하며 새로운 IP 주소를 할당하기 때문에 사용자를 특정할 수 없습니다.

만약 사용자를 식별하자고 변조된 클라이언트 IP를 복원하는 것 자체가 보안에 의미가 없는 행동이 됩니다.

 

3) 프록시나 게이트웨이를 사용하면, 원서 버는 클라이언트 IP를 모르게 된다.

원 서버는 프록시와 게이트웨이와 통신하기 때문에 그들의 IP 주소만 알지 클라이언트 IP 주소는 알지 못합니다.

이를 해결하기 위해 'Client-IP', 'X-Forwarded-For' 헤더를 사용하나, 모든 프록시들이 지원하지 않아 문제가 생깁니다.

 

2. 사용자 로그인을 통한 식별

이렇게 문제가 많은 클라이언트 IP 주소 대신, 사용자 이름(ID)와 비밀번호로 인증을 요구해 사용자를 식별하는 방식입니다. 이를 위해서 '401 Login-Required 응답 코드', 'WWW-Authenticate'와 'Authorization' 헤더를 이용합니다.

그림 1 간단한 로그인 과정

간단하게 그림 1과 같은 순서대로 로그인 과정이 이루어집니다.

 

STEP 1

클라이언트가 콘텐츠(데이터)를 서버에 요청을 하면...

 

STEP 2

서버가 이 콘텐츠가 아무나 접근이 가능한지, 아닌지를 판별한 후 만약 사용자 인증이 필요하다면 인증을 요구합니다. (로그인) 여러분들이 자주 보는 로그인 창이 서버가 '401 Login-Required 코드'와 함께 'WWW-Authenticate'를 전송하며 팝업 됩니다!

 

STEP 3 

인증이 성공적으로 이루어지면, Authorization 헤더에 사용자 정보를 담아 전송합니다. 이는 매 요청마다 전송해 세션이 끝날 때까지 식별을 유지하게 합니다.

 

STEP 4

사용자를 식별한 서버는 요청받은 데이터를 응답 메시지에 담아 전송합니다.

 

---

쿠키

기본적인 보안이 되어있는 업체 건물을 가면, 처음 입장을 할 때 임시 출입증을 발급해줍니다. 이를 통해 건물 밖을 잠시 나가야 하는 경우가 있더라도, 매번 신원을 확인할 필요 없이 출입증만 제시하면 쉽게 통과를 할 수 있습니다.

컴퓨터도 마찬가지입니다. 서버를 방문하거나 데이터를 요청할 때마다 매번 인증을 해야 한다면 사용자들은 큰 피로감을 느낄 겁니다. 그래서 똑같이 임시 출입증을 발급하는 방식을 사용하고 있습니다. 앞서 설명한 Authorization 헤더에 사용자 정보를 담아 매 요청마다 전송함으로써 세션 간 사용자 식별을 유지를 했었죠. 쿠키 역시 Authorization 헤더와 같은 기능을 수행하는 방식입니다. 이제부터 본격적인 쿠키에 대해 알아봅시다.

 

 

1. 쿠키의 종류

쿠키의 종류는 크게 파기 시점에 따라 '세션 쿠키'와 '지속 쿠키'로 나뉩니다. 파기 시점은 앞서 캐시에서 배운 'Expires', 'Max-Age' 헤더로 정합니다.

 

1) 세션 쿠키

임시적으로 저장하는 쿠키입니다. 주로 브라우저에 저장되며, 이 브라우저를 닫으면 삭제가 됩니다. 

즉시 삭제가 되기 때문에, 'Expires' 'Max-Age' 헤더가 필요 없습니다!

(예 : 쇼핑몰 검색 필터 정보)

 

2) 지속 쿠키

삭제되지 않고 디스크에 저장되어 더 길게 유지되는 쿠키입니다. 디스크에 저장되기 때문에, 컴퓨터를 끄더라도 남아있습니다.

'Expires' 'Max-Age' 헤더가 필요합니다.

(예 : 자동 로그인, 페이지 설정 정보 등등)

 

 

2. 쿠키의 구성요소

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

'Set-Cookie'와 'Cookie'응답 헤더로 구성되어있습니다.

'이름 = '값 속성은 필수로 들어가야 하는 속성이고, 나머지는 선택 속성입니다.

 

'Set-Cookie'의 속성

속성	설명	예시
'이름 = 값'	이름과 값 모두 세미콜론, 쉼표, 등호, 공백 포함 X	Set-Cookie:  customer=Mary
'Expires'	쿠키의 수명입니다. 이 날짜를 지나면 파기됩니다.	Set-Cookie: name=value; expires=Wednesday, 09-Nov-99 23:12:40 GMT
'Domain'	특정 도메인 명을 입력해 그 도메인으로만 쿠키를 전송	Set-Cookie: name=value; domain="tistory.com"
'Path'	서버에 있는 특정 경로의 문서에만 쿠키를 할당.	Set-Cookie:  name=value; path=/orders
'Secure'	HTTP가 SSL 보안 연결을 사용할때만 쿠키를 전송.	Set-Cookie: name=value; secure

 

 

2) Version 1 (RFC 2109 or RFC 6265)

값이 1로 설정된 경우에 Cookie RFC 2109를 준수해야 합니다.

Set-Cookie2 HTTP 응답 헤더를 수신하여 자동으로 생성된 경우 규칙은 RFC 2965로 설정됩니다.

RFC 2965 쿠키가 존재했으나 지금은 폐기되었고. 이후 RFC 6265로 개선되었다.

 

 

3. 쿠키의 간단한 동작 방식

그림 2 쿠키의 간단한 동작 방식

 

STEP 1 : 서버 첫 방문

사용자가 서버에 첫 방문을 하면, 서버가 사용자에게 쿠키를 할당합니다.

 

STEP 2 : 쿠키 저장

사용자가 할당받은 쿠키를 브라우저나 디스크에 저장을 합니다.

 

STEP 3 : 재 방문시 쿠키 사용

이후 서버 재 방문을 할 때마다 받은 쿠키를 메시지에 담아 전송을 합니다.

이를 '클라이언트 측 상태', 'HTTP 상태 관리 체계'라고 합니다.

 

STEP 4 : 받은 쿠키를 통한 사용자 식별

받은 쿠키를 통해 사용자의 정보를 불러옵니다.

 

 

4. 주의사항

1) 모든 쿠키를 전송하지는 않는다.

브라우저가 수많은 쿠키를 가질 수 있으나, 성능 문제나 보안 문제 때문에 5개 안의 쿠키만을 전송합니다.

성능 문제로는, 쿠키 전체를 보내버리면 콘텐츠의 용량보다 쿠키의 용량이 더 커 배보다 배꼽이 더 커지는 것이 첫 번째 이유이고, 쿠키 대부분이 크게 중요하지 않은 정보를 가지고 있기 때문입니다.

보안 문제로는 만약 신뢰하지 않는 사이트의 경우 쿠키를 보내버리게 되면, 개인정보 유출의 문제가 발생하기 때문입니다.

2) 쿠키가 캐싱되는 것을 주의해라.

(1) 캐시가 되어야 할, 되지 않아야 할 문서를 명확하게 구분하라.

다른 이에게 개인정보가 노출되는 상황이 발생할 수 있습니다. 그렇기 때문에 쿠키를 주의해서 관리를 해야 합니다.

만약 쿠키가 캐싱되는 것을 원치 않는다면 Cache-Control: no-cache를, Set-Cookie 헤더를 제외하고 싶다면,

Cache-Control: no-cache="Set-Cookie"를 명시해야 합니다.

캐시를 해도 되는 문서는 Cache-Control: public를 명시합시다. 대역폭을 절약할 수 있습니다.

 

(2) Set-Cookie 헤더를 캐시 하는 것에 유의해라.

같은 'Set-Cookie' 헤더가 여러 사용자에게 가면, 사용자 추적에 어려움이 생깁니다.

또한 몇몇 캐시는 'Set-Cookie' 헤더를 제거하기 때문에, 클라이언트는 'Set-Cookie' 헤더를 받지 못해 문제를 만들 수 있습니다. 이를 해결하기 위해서 Cache-Control: must-revalidate, max-age=0을 명시해 반드시 재검사를 하도록 합시다.