FE/BOOK

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

<zinny/> 2025. 1. 2. 19:31
728x90

HTTP가 사용자를 식별하는데 사용하는 기술들

 

1. HTTP헤더

 

다양한 헤더를 통해서 사용자에 대한 정보를 알 수있다. 

악의적인 서버가 From헤더에 있는 이메일 주소를 모아서 스팸 메일을 발 송 하는 문제가 있어서 From헤더를 보내는 브라우저는 많지 않다.

웹로복은 데이터르를 수집 하는 과정에 의도치 않게 웹사이드에 문제를 일으키는 경우 항의메일을 보낼 수 있도록 From헤더를 기술하기도 한다. 

 

user-agent는 사용자가 쓰고있는 브라우저의 이름과 버전정보, 때로는 운영체제에 대한 정보까지 포함해서 알려주기도 한다. 특정 브라우저에 동작에 관한 처리를 하기엔 좋지만, 콘텐츠를 최적화 하기에 유용한 정보는 아니다. 

2. 클라이언트IP주소

클라이언트의 IP주소는 보통 헤더에는 없지만, HTTP요청을 보내는 반대쪽 TCP 커넥션의 IP주소를 알아낼 수있다.

 

  • IP주소는 사용자가 아닌, 사용하는 컴퓨터를 가르키기 때문에, 여러 사용자가 같은 컴퓨터를 사용하는 경우 식별이 어렵다.
  • ISP는 사용자가 로그인 하면 동적 IP주소를 할당 한다. 사용자는 매번 다른 주소를 받기 때문에 식별이 어렵다.
  • 보안 강화를 위해서 사용자는 네트워크주소 변환 방화벽을 통해 인터넷을 사용하기도 한다.
  • HTTP프락시와 게이트웨이는 원서버에 새로운 TCP연결을 하기 때문에, IP주소 대신 프락시 서버의 IP주소를 본다. 

보안기능으로 IP주소를 사용하여, 특정IP주소로 오는 사용자에게만 문서를 전달하기도 한다. (인트라넷 같은) 하지만 인터넷에서는 IP주소를 임의 변경이 가능하기 때문에 문제 발생의 여지가 있다. 

3. 사용자 로그인

사용자의 이름과 비번 인증 요구를 통해 사용자에게 명시적 식별을 요청 할 수 있다.

4. 뚱뚱 URL

URL마다 버전을 기술하여 사용자를 식별하고 추적하는 경우가 있다. 사용자의 상태 정보를 포함한 URL을 뚱뚱한 URL이라고 부른다. 

하지만 아래와 같은 문제가 발생 할 수 있음

  • 사용자들에게 혼란을 줄 수 있음
  • 누적된 개인정보를 공유하게 될 수 있음 
  • 캐시 사용이 불가능
  • 서버 부하 가중
  • 사용자 이탈의 가능성
  • 세션간의 지속성의 부재 

5. 쿠키

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

 

세션쿠키 VS 지속쿠키

세션쿠키는 사용자가 사이트를 탐색할 때, 관련 설정과 선호사항을 저장하는 임시 쿠키로, 브라우저를 닫으면 삭제된다. 

지속쿠키는 삭제되지 않고 남아있으며, 디스크에 저장되어 컴퓨터를 닫더라도 유지된다.

 

쿠키는 Discard 파라미터가 있거나, Expires또는 Max-age파라미터가 없으면 세션쿠키가 된다. 

 

쿠키는 임의의 이름 = 값 형태의 리스트를 가지고, 리스트는 Set-cookie 또는 Set-Cookie2같은 HTTP응답 헤어데 기술되어 전달된다. 

 

클라이언트 측 상태

블라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때마다 정보를 함께 전송하게 하는 것이다. 

브라우저는 쿠키 정보를 저장할 책임이 있는데 이것을 클라이언트 측 상태 라고 한다.

공식적인 이름은 HTTP 상태 관리 체계 이다.

각 브라우저는 각기 다른 방식으로 쿠키를 저장한다.

 

브라우저는 엄청 많은 쿠키를 가지고 있을 수 있지만 쿠키 전부를 모든 사이트에 보내지 않는다. (최대 2~3개 정도만 보냄) 

이유는

  • 성능저하
  • 서버에 특화된 값을 포함하고 있기 때문에 대부분의 사이트에서 인식하지 않는 무의미한 값이기 때문
  • 특정사이트에서 제공한 정보를 신뢰하지 않는 사이트에서 가져갈 수 있어, 잠재적 개인정보 문제가 일어날 수 있음

 

브라우저는 보통 쿠키를 생성한 서버에게만 정보를 전달 하는데, 광고를 위해서 다른 서버에도 전달하기도 한다. 

 

쿠키 전달 방식

  1. 서버는 쿠키를 생성할때 응답헤더에 도메인 속성을 기술해 어떤 사이트가 그 쿠키를 읽을 수 있는지 제어 가능하다.
  2. 웹 사이트 일부에만 쿠키를 적용할 수 있다. URL앞부분을 가르키는 path 속성을 기술해 경로에 포함되는 페이지에만 쿠키를 전달한다. 

Version 0(넷스케이프) 쿠키

최초의 쿠키 명세는 네스케이프가 정의했는데

  • 이름 = 값 : 필수 속성으로 이름과 값 모두 세미콜론,쉼표,등호,공백을 포함하지 않는 문자열이다.
  • Expires : 선택 속성으로 쿠키의 생명주기를 가리키는 날짜 문자열을 기술한다 .
  • Domain : 선택 속성으로 브라우저는 이 속성에 기술된 도메인을 사용하는 서버 호스트명으로만 쿠키를 전송한다.
  • Path : 선택 속성으로 서버에 있는 특정 문서에만 쿠키를 할당할 수 있다.
  • Secure :  선택 속성으로 쿠니는 HTTP가 SSL보안 연결을 사용할 때만 쿠키를 전송한다, 

Version 1(RFC 2965) 쿠키

 

쿠키와 세션 & 캐싱

쿠키는 사용자를 추적하는데 사용한다.

쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 이전 사용자의 쿠키가 다른 사용자에게 할당되어 개인정보 노출의 위험성이 있어 주의 해야한다. 

 

캐시를 다루는 기본 원칙 

  1. 캐시되지 말아야 할 문서가 있다면 표시해야한다. Cache-Control: no-cache='Set-Cookie'
  2. Set-Cookie 헤더를 캐시하는 것에 유의해야 한다. 같은 헤더를 여러 사용자에게 보내면 사용자 추척에 실패하기 때문이다. 
  3. Cookie 헤더를 가지고 있는 요청을 주의해야한다. 요청이 Cookie헤더와 함께 오면, 콘텐츠가 개인정보를 담고 있을 수 있다는 힌트기 때문에 개인정보는 캐시되지 않도록 되어야 한다. 
728x90