[HTTP] 클라이언트 식별과 쿠키(Cookie)

 

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

---

#1. HTTP 헤더

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

 

From 헤더

사용자의 이메일 주소를 포함한다. 사용자가 서로 다른 이메일 주소를 가지므로 사용자를 식별할 수 있다. 하지만 악의적인 서버가 이메일 주소를 모아서 스팸 메일을 발송하는 문제가 있어서 From 헤더를 보내는 브라우저는 많지 않다.

User-Agent 헤더

사용자가 쓰고 있는 브라우저의 이름과 버전정보, 어떤 경우에는 운영체제에 대한 정보까지 포함하여 서버에게 알려준다. 특정 사용자를 식별하는데는 큰 도움이 되지 않는다. (콘텐츠 최적화에 유용)

Referer 헤더

현재 페이지로 유입하게 한 웹페이지의 URL을 가리킨다. 사용자를 식별할 수는 없지만 사용자가 이전에 어떤 페이지를 방문했는지 알려준다. (웹 사용 형태나 사용자의 취향 파악 유용)

---

#2. 클라이언트 IP 주소

초기 웹 선구자들은 사용자 식별에 클라이언트의 IP 주소를 사용하려 했다. 이 방식은 사용자가 확실한 IP 주소를 가지고 있고 그 주소가 바뀌지 않고 웹 서버가 요청마다 클라이언트의 IP를 알 수 있다면 문제없이 동작한다.

클라이언트 IP 주소로 사용자를 식별하는 방식의 약점

• IP 주소는 사용자가 아닌 컴퓨터를 카리킨다. 여러 사용자가 같은 컴퓨터를 사용한다면 식별하기 어렵다.
• 많은 인터넷 서비스 제공자(ISP)는 사용자가 로인하면 동적으로 IP주소를 할당한다. 사용자는 매번 다른 주소를 받으므로 식별하기 어렵다.
• 보안 강화를 위해 많은 사용자가 네트워크 주소 변환(NAT) 방화벽을 통해 인터넷을 사용한다. 
• HTTP 프라시와 게이트웨이는 원 서버에 새로운 TCP를 연결하고 웹 서버는 프락시 서버의 IP주소를 본다. 일부 프락시는 원본 IP주소를 보존하려고 Client-ip나 X-forwarded 확장 헤더를 추가하여 문제를 해결하려 했지만 모든 프락시가 이런 식으로 동작하진 않는다.

---

#3. 사용자 로그인

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

웹 사이트 로그인이 더 쉽도록 HTTP는 WWW-Authenticate와 Authorization 헤더를 사용해 웹 사이트에 사용자 이름을 전달하는 자체적인 체계를 가지고 있다.

서버에서 사용자가 사이트에 접근하기 전에 로그인을 시키고자 한다면 HTTP 401 Login Required 응답 코드를 브라우저에 보낼 수 있다. 브라우저는 로그인 대화장자를 보여주고 다음 요청부터 Authorization 헤더에 그 정보를 기술하여 보낸다.

HTTP 인증 헤더를 사용하여 사용자 등록하기

---

#4. 쿠키(Cookie)

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

쿠키의 타입

• 세션 쿠키 : 사용자가 사이트를 탐색할 때 관련한 설정과 선호 사항들을 저장하는 임시 쿠키, 사용자가 브라우저는 닫으면 삭제된다.
• 지속 쿠키 : 디스크에 저장되어 브라우저를 닫거나 컴퓨터를 재시작하더라도 남아있다. 사용자가 주기적으로 방문하는 사이트에 대한 설정 정보나 로그인 이름을 유지하기 위해 사용

---

쿠키는 어떻게 동작하는가

 

사용자에게 쿠키 할당

(a) - 처음에 사용자가 웹 사이트를 방문하면 웹 서버는 사용자에 대해서 아무것도 모른다. 

(b) - 웹 서버는 사용자가 다시 돌아왔을 때 사용자를 식별하는 유일한 값을 쿠키에 할당 (Set-cookie: id:"34294")

(c) - 사용자가 미래에 같은 사이트를 방문하면 브라우저는 서버가 사용자에게 할당했던 쿠키를 헤더에 기술해 전송

---

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

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

• 쿠키를 모두 전달하면 성능이 크게 저하된다. 
• 서버에 특화된 이름/값 쌍을 포함하고 있기 때문에 대부분 사이트에서는 인식하지 않는 무의미한 값이다.
• 신뢰하지 않는 사이트에서 가져갈 수 있으므로 잠재적인 개인정보 문제가 생긴다.

---

Version 0(넷스케이프) 쿠키

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

Set-Cookie 속성	설명
이름 = 값	Set-Cookie: cusromet=Mary , 필수속성
Expires	Set-Cookie: foo=bar; expires=Monyday, 09-Nov-99 23:12:40 GMT
Domain	Set-Cookie: SHIPPING=FEDEX; domain="joes-hardware.com"
Path	Set-Cookie: lastorder=00183; path=/orders
Secure	Set-Cookie: private_id=519; secure

---

Version 1 (RFC 2965) 쿠키

쿠키의 확장된 버전은 RFC 2965에 정의되어 있다. Version 1 표준은 Set-Cookie2와 Cookie2 헤더를 소개하고 있으며 Version 0 시스템과도 호환된다. RFC 2965 쿠키 표준은 원 버전인 넷스케이프 표준보다 좀 더 복잡하며 아직 모든 브라우저나 서버가 완전히 지원하지는 않는다.

RFC 2965에서 추가된 주요 변경사항

• 쿠키마다 그 목적을 설명하는 설명문이 있다.
• 파기 주기에 상관없이 브라우저가 닫히면 쿠키를 강제로 삭제할 수 있다.
• 초 단위의 상대 값으로 쿠키의 생명주기를 결정할 수 있다. (Max-Age)
• 도메인과 경로뿐 아니라 URL의 포트번호로도 쿠키를 제어할 수 있다.
• 도메인, 포트, 경로 필터가 있으면 Cookie 헤더에 담겨 되돌려 보낸다.
• 호환되는 버전 번호
• 사용자 이름과 추가적인 키워드를 구별하기 위해 Cookie 헤더에 $ 접두사가 있다.

---

쿠키와 해싱

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

• 캐시되지 말아야 할 문서가 있다면 표시 : 문서가 Set-Cookie 헤더를 제외하고 캐시를 해도 될 경우라면 Cache-Control: no-cache="Set-Cookie"를 기술해서 명확히 표시한다. 
• Set-Cookie 헤더를 캐시 하는 것에 유의 : 응답이 Set-Cookie 헤더를 가지고 있으면 본문은 캐시할 수 있지만 Set-Cookie 헤더를 캐시하는 것은 주의를 기울여야만 한다.
• Cookie 헤더를 가지고 있는 요청을 주의 : 요청이 Cookie 헤더와 함께 오면 결과 콘텐츠가 개인정보를 담고 있을 수도 있다는 힌트다.

---

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

쿠키를 사용하지 않도록 비활성화시킬 수 있고 로그 분석 같은 다른 방법으로 대체하는 것도 가능하므로 보안상으로 엄청나게 위험한 것은 아니다.

개인정보를 다루거나 사용자를 추적하는 기술은 잘못된 의도로 사용될 수 있기 때문에 항상 조심하는 것이 좋다. 쿠키에 대한 부정적인 여론이 많기는 하지만 제공하는 개인정보를 누가 받는지 명확히 알고 사이트의 개인정보 정책에만 유의한다면 쿠키에 관련한 위험성보다 세션 조작이나 트랜잭션상의 편리함이 더 크다.

---

 

참고 자료

• HTTP완벽가이드 , 인사이트