11.1 개별 접촉
- HTTP는 익명으로 사용하며 상태가 없고 요청과 응답으로 통신하는 프로토콜임
- 서버는 클라이언트가 보낸 요청을 처리하고 나서 그 응답을 클라이언트로 전송
- 웹 서버는 요청을 보낸 사용자를 식별하거나 방문자가 보낸 연속적인 요청을 추적하기 위해 약간의 정보 이용 가능
- 현대에는 개인화된 서비스 제공을 원함
개별 인사
- 온라인 쇼핑이 개인에게 맞춰져 있는 것처럼 느끼게 하기 위해 개인 환영 메시지, 내용 제공
사용자 맞춤 추천
- 고객의 흥미가 무엇인지 학습하여 특별한 정보 제공
저장된 사용자 정보
- 사용자의 정보를 저장 후 식별하여 사용자가 반복적으로 처리해야 하는 과정들을 생략할 수 있도록 도움
세션 추적
- HTTP 트랜젝션은 상태가 없음
- 각 요청은 독립적으로 이루어짐
- 사용자가 사이트와 상호작용할 수 있도록 사용자의 상태를 남김. 웹 사이트는 사용자에게서 오는 HTTP 트랜젝션을 식별할 방법이 필요
11.2 HTTP 헤더
사용자에 대한 정보를 전달하는 7가지 헤더
- From
- 요청
- 사용자의 이메일 주소
- User-Agent
- 요청
- 사용자의 브라우저
- Referer
- 요청
- 사용자가 현재 링크를 타고 온 근원 페이지
- Authorization
- 요청
- 사용자 이름과 비밀번호
- Client-ip
- 확장
- 클라이언트의 IP 주소
- X-Forwarded-For
- 확장
- 클라이언트의 IP 주소
- Cookie
- 확장
- 서버가 생성한 ID 라벨
11.3 클라이언트 IP 주소
- 초기 웹 선구자들은 사용자 식별에 클라이언트 IP 주소를 사용하려 함
- 안타깝게도 클라이언트 IP 주소로 사용자를 식별하는 방법은 약점들을 가짐
- 클라이언트 IP는 사용자가 아닌, 사용하는 컴퓨터를 가리킴. 여러 사람이 같은 컴퓨터를 사용한다면 식별 불가능
- 로그인하면 동적으로 IP를 할당. 로그인한 시간에 따라 사용자는 매번 다른 주소를 받으므로 식별 불가능
- 등등 여러 문제들이 존재
11.4 사용자 로그인
- IP 주소로 사용자를 식별하려는 수동적인 방법보다, 사용자의 이름과 비밀번호로 인증할 것을 요구
- 사이트에서 한번만 로그인하면 브라우저는 해식별정보 토큰을 헤더에 담아 서버로 전송하여 한 세션 내내 식별 유지 가능
11.5 뚱뚱한 URL
- 어떤 웹 사이트는 사용자의 URL마다 버전을 기술하여 식별 및 추적 진행
- 사용자가 해당 사이트를 돌아다니면, 웹 서버는 URL에 있는 상태 정보를 유지하는 하이퍼링크를 동적으로 생성
- 사용자의 상태 정보를 포함하는 URL
- 세션, 방문으로 묶는 용도로 뚱뚱한 URL 사용
뚱뚱한 URL의 문제점
- 못생긴 URL
- 브라우저에 보이는 뚱뚱한 URL은 새 사용자에게 혼란을 줌
- 공유하지 못하는 URL
- 뚱뚱한 URL은 특정 사용자와 세션에 대한 상태 정보를 포함 (유출 가능성)
- 캐시를 사용할 수 없음
- URL로 만드는 것은 URL이 달라지기 때문에 기존 캐시에 접근할 수 없다는 것을 의미
- 서버 부하 가중
- 서버는 뚱뚱한 URL에 해당하는 HTML 페이지를 다시 그려야 함
- 이탈
- 사용자가 링크를 타고 다른 사이트로 이동하거나 특정 URL을 요청해서 의도치 않게 뚱뚱한 URL을 이탈하기 쉬움
- 세션 간 지속성의 부재
- 사용자가 특정 뚱뚱한 URL을 북마킹하지 않는 이상, 로그아웃하면 모든 정보를 잃음
11.6 쿠키
- 쿠키는 사용자를 식별하고 세션을 유지하는 방식 중에서 현재까지 가장 널리 사용하는 방식
- 쿠키는 앞서 설명한 문제들을 겪지는 않지만, 쿠키만으로 안되는 일에는 앞서 설명한 기술들을 함께 사용
11.6.1 쿠키의 타입
- 세션 쿠키
- 사용자가 사이트를 탐색할 때, 관련한 설정과 선호 사항들을 저장하는 임시 쿠키
- 브라우저를 닫으면 삭제
- 지속 쿠키
- 삭제되지 않고 더 길게 유지될 수 있음
- 지속 쿠키는 디스크에 저장되어, 브라우저를 닫거나 재시작하더라도 남아있음
11.6.2 쿠키는 어떻게 동작하는가
- 사용자가 웹 사이트에 방문하면 웹 사이트는 서버가 사용자들에게 붙인 모든 (식별)스티커를 읽을 수 있음
- 웹 서버는 사용자를 식별하기 위한 유일한 값을 쿠키에 할당
- 쿠키는 어떤 정보든 포함 가능하지만, 서버가 사용자 추적 용도로 생성한 유일한 단순 식별 번호만 포함하기도 함
11.6.3 쿠키 상자: 클라이언트 측 상태
-
쿠키의 기본적인 발상은 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때마다 그 정보를 함께 전송하게 하는 것
-
종류
- 구글 크롬 쿠키
- SQLite 파일에 쿠키를 저장
- 마이크로소프트 인터넷 익스플로러 쿠키
- 캐시 디렉터리에 각각의 개별 파일로 쿠키를 저장
- 파일에 있는 각 쿠키 첫 번째 줄은 쿠키의 이름
- 구글 크롬 쿠키
11.6.4 사이트마다 각기 다른 쿠키들
- 브라우저는 수백 수천 개의 쿠키를 가지고 있을 수 있지만, 쿠키 전부를 모든 사이트에 보내지는 않음
- 보통 각 사이트에 2~3개의 쿠키만을 보냄
- 이유
- 쿠키 모두 전달 시 성능 저하
- 쿠키 대부분은 서버에 특화된 이름/값 쌍을 포함하고 있기 때문에 사이트에서는 인식하지 않는 무의미한 값
- 특정 사이트에서 제공한 정보를 신뢰하지 않는 사이트에 가져갈 수 있어 잠재적인 개인정보 문제 발생
- 쿠키 Domain 속성
- 서버는 쿠키를 생성할 때 Set-Cookie 응답 해더에 Domain 속성을 기술
- 어떤 사이트가 그 쿠키를 읽을 수 있는지 제어 가능
- 쿠키 Path 속성
- 웹 사이트 일부에만 쿠키 적용 가능
- URL 경로의 앞부분을 가리키는 Path 속성을 기술해서 해당 경로에 속하는 페이지에만 키를 전달
11.6.5 쿠키 구성요소
- (생략)
11.6.6 Version 0(넷스케이프) 쿠키
- 최초의 쿠키 명세는 넷스케이프가 정의
- 응답 헤더와 Cookie 요청 헤더와 쿠키를 조작하는 데 필요한 필드들을 정의
- Version 0 Set-Cookie 헤더
- Set-Cookie 헤더는 쿠키의 이름과 값을 가져야 함
- Version 0 Cookie 헤더
- 클라이언트가 서버에 요청을 보낼 때는 Domain, Path, Secure 필터들이 현재 요청하려고 하는 사이트에 들어맞으면서 아직 파기되지 않은 쿠키들을 함께 보냄
11.6.7 Version 1 (RFC 2965) 쿠키
- 해당 표준은 원 버전인 넷스케이프 표준보다 좀 더 복잡하며, 아직 모든 브라우저나 서버가 완전히 지원하지는 않음
11.6.8 쿠키와 세션 추적
- 쿠키는 웹 사이트에 수차례 트랜잭션을 만들어내는 사용자를 추적하는 데 사용
- 브라우저에 입력
→ 일련의 리다이렉트, URL 리라이트, 쿠키설정
→ 서버가 식별 정보를 첨부하기 위한 연속적은 트랜젝션 시작
11.6.9 쿠키와 캐싱
- 쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 주의
- 이전 사용자의 쿠키가 다른 사용자에게 할당돼버리거나, 누군가의 개인 정보가 다른 이에게 노출되는 상황 생길 수 있음
캐시를 다루는 기본 원칙에 대한 안내
- 캐시되지 말하야 할 문서가 있다면 표시하라
- Set-Cookie 헤더를 캐시하는 것에 유의하라
- Cookie 헤더를 가지고 있는 요청에 주의하라
11.6.10 쿠키, 보안 그리고 개인정보
- 쿠키를 사용하지 않도록 비활성화 시킬 수 있고, 로그 분석 같은 다른 방법으로 대체하는 것도 가능
- → 그 자체가 보안상으로 엄청나게 위험한 것은 아님
- 원격 DB에 개인 정보 저장, 해당 키 값을 쿠키에 저장하는 방식을 표준으로 사용하면 클라이언트와 서버 사이에 예민한 데이터가 오가는 것 최소화 가능
- 👉제공하는 개인정보를 누가 받는지 명확히 알고 사이트 개인정보 정책에만 유의한다면, 쿠키 관련 위험성보다 세션 조작이나 트랜잭션의 편리함이 더 큼
노력하는 초보 개발자