16. 클라이언트 식별과 쿠키

16. 클라이언트 식별과 쿠키(~ing)

개별 접촉

• HTTP는 익명으로 사용되며, 상태가 없고 요청과 응답으로 통신하는 프로토콜이다.
• 현대의 웹사이트들은 개인화된 서비스를 제공하고 싶어한다.
  • 사용자 별 개별인사, 맞춤 추천, 정보, 세션 추적 등으로 사용자를 식별하여 정보를 제공 할 수 있다.

사용자 식별 기술

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

---

HTTP 헤더

From

• Type : 요청
• 사용자의 이메일 주소
• 악의적으로 정보를 뽑아 스팸메일을 보낼 수 있으므로, 해당 헤더를 보내는 브라우저는 많지 않다.

User-Agent

• Type : 요청
• 사용자 브라우저
• 사용자가 사용하고 있는 브라우저의 이름, 버전 어떤 경우에는 사용중인 OS에 대한 정보까지도 알려준다.

Referer

• Type : 요청
• 사용자가 현재 링크를 타고 온 근원페이지
• 사용자가 요청을 보낸 페이지의 주소를 알려준다.
• 사용자의 정보를 알 순 없지만, 이전에 어떤 페이지를 방문했는지를 알려준다.

Authorization

• Type : 요청
• 사용자 이름과 비밀번호

Client-ip

• Type : 확장(요청)
• 클라이언트의 IP 주소

X-Forwarded-For

• Type : 확장(요청)
• 클라이언트의 IP 주소

Cookie

• Type: 확장(요청)

---

클라이언트 IP 주소

클라이언트 IP주소로 사용자 식별시 단점

• IP주소는 사용자가 아닌 컴퓨터의 주소를 가르킨다. 만약, 한 컴퓨터를 다수가 사용한다면 식별 할 수 없다.
• 많은 인터넷 서비스 제공자(ISP)는 사용자가 로그인을 하면 동적으로 IP를 할당한다. 로그인 시간에 따라 매번 IP가 변경 될 수 있으므로 식별 할 수 없다.
• 많은 사용자가 네트워크 주소 변환 방화벽을 통해 인터넷을 사용하므로 식별 할 수 없다.
  이 NAT(NetWork Address Translation) 장비들은 실제 IP를 방화벽 뒤로 숨긴다.
• HTTP프락시 or 게이트웨이를 거쳐올 경우, 몇몇 프락시들은 기존 IP를 보존하려 Client-ip나 X-Forward-For와 같은 확장 헤더를 사용하는데 모든 프락시들이 이를 사용하진 않으므로 식별 할 수 없다.

인트라넷과 같은 제한적인 환경에서는 적절할 수 있다. But….

• 인터넷에서는 IP 주소를 임의로 변경할 수 있기 때문에 문제가 발생 할 수 있다.
  • 클라이언트와 서버 사이에 있는 프락스도 문제가 발생 할 수도 있다.

---

사용자 로그인

• 서버는 요청에 대한 응답으로 사용자 정보를 요구할 수 있다.
• 상태코드 401 Login Requried를 보내 로그인을 하라는 응답을 보낼 수 있다.
• 하지만, 매번 다른 사이트에 이동할 때마다 로그인을 해야하는 번거로움이 발생한다.
  • 만약, 내가 사용하는 아이디를 누가 선점했다면, 그에 해당하는 사이트의 회원정보를 다 외워야 한다.

---

뚱뚱한(fat) URL

• 사용자의 상태정보를 포함하고 있는 URL을 말한다.
• 사용자가 웹사이트를 처음 방문하면 고유 값을 부여해 URL에 계속 달고다니면서 사용자를 추적한다.
• 아래의 경우 002-1145265-8016838 를 통해 사용자를 뚱뚱한 URL로 추적하고 있다.

<a href="/exec/obid/sdff/ref=gr-sdf/002-1145265-8016838">h</a>
<a href="/exec/obid/sdff/ref=gr-sdf/dfdf/002-1145265-8016838">kk</a>
<a href="/exec/obid/sdff/ref=gr-sdf/sfdf/ttt/002-1145265-8016838">sdlkfj</a>
...

단점

• 못생긴 URL로 인해 사용자에게 혼란을 준다.
• 공유하지 못하는 URL로 세션이 없다면 해당 URL로는 정보 공유가 불가능하며 세션이 있다면 정보가 노출됨
• 캐시를 사용할 수 없는 URL로 URL이 달라지므로 기존 세션이 접근할 수 없게된다.
• 서버 부하를 가중시키는 URL로 뚱뚱한 URL에 해당하는 HTML페이지를 다시 그려야 한다.
• 기존 서비스에서만 지속되므로 잠시 다른 사이트로 이탈시 사용이 중지된 URL이 된다.
• 사용자가 뚱뚱한 URL을 북마킹하지 않는이상!! 로그아웃하면 모든 정보를 잃게 된다.

---

Cookie

• 사용자를 식별하는 기술 중 가장 널리 사용중인 기술
• 이름 = 값의 형태를 가진다.
• 웹서버가 Set-Cookie, Set-Cookie2(확장헤더)로 HTTP 응답 헤더에 기술되어 사용자에게 전달한다.
• 각각의 브라우저 마다 저장 방법을 달리 한다.
  • 크롬→ Cookie 한 개에 13개의 필드가 존재한다.
  • → Cookies라는 SQLite 파일에 쿠키를 저장한다.
  • 마이크로소프트 인터넷 익스플로러쿠키를 확인하려면 해당 디렉터리를 뒤져 볼 수 있다.
  • → Cache 디렉터리에 각각의 개별 파일로 쿠키를 저장한다.

Cookie 타입

• 세션쿠키→ 브라우저를 닫으면 삭제된다.
• → 사용자가 사이트를 탐색 할 때 설정한 환경, 선호 사항들을 저장하는 임시쿠키
• 지속쿠키사용자가 주기적으로 방문하는 사이트에 대한 설정 정보 or 로그인 이름을 유지하기 위해 사용한다.
• → 디스크에 저장하며 브라우저를 닫거나 컴퓨터를 재부팅시에도 여전히 남아 있다.
• 두 쿠키의 구분점은 파기 시점이다.
  • Discard 파라미터가 설정되어 있거나 Exprires or Max-Age가 없으면 세션쿠키다.

Cookie Box: 클라이언트 측 상태

• Cookie의 기본적인 발상은 브라우저가 서버의 정보를 저장하고, 서버 접근시 그 정보를 함게 전송하는 것
• 브라우저는 쿠키 정보를 저장할 책임이 있는데, 이를 클라이언트 측 상태라고 한다.
  • Cookie명세서에서의 공식적인 이름은 ‘HTTP 상태 관리 체계’라고 한다.

사이트마다 각기 다른 Cookie

• 브라우저는 모든 사이트에 Cookie를 보내지 않는다.
  • 실제 콘텐츠보다 큰 바이트를 서버에게 전달하게 되기 때문이다.
  • 서버에 특화된 이름/값 쌍으로 구분되기 때문에 무의미한 데이터가 전송되게 되기 때문이다.
  • 신뢰하지 않는 사이트에 개인정보고 유출될 우려가 있기 때문이다.
• Set-Cookie 응답헤더에 Domain 속성을 통해 특정 사이트에만 Cookie를 보내게 할 수 있다.
• Set-Cookie 응답헤더에 Path 속성을 통해 해당 Domain의 특정 페이지에만 Cookie를 전달할 수 있게 설정할 수 있다.

Version 0(넷스케이프) Cookie

• 최초의 쿠키 명세 - 넷스케이프가 정의함
• 쿠키 옵션들은 ;(세미콜론)으로 구분 짓는다.
• 다양한 옵션들을 명세할 수 있는데 이는 key=value 형태로 작성한다.
  • key=value
  • → 그 어떠한 조합도 만들어 옵션을 생성 할 수 있다.
  • Expires→ 요일, DD-MM-YY HH:MM:SS GMT 형태로 작성한다.(사용 할 수 있는 유일한 타임 존)
  • → 해당 쿠키의 생명 주기를 작성한다.
  • Domain→ 적어도 두개 ~ 세개의 영역을 선언해주어야 한다.→ 그 외에는 세개를 입력해야 한다.
  • → .com .net .org .gov 등과 같이 특정 최상위 도메인들은 두개를 입력한다. naver.com
  • → 해당 Cookie를 사용 할 사이트의 주소를 작성하는 옵션
  • Path→ / 를 앞에 붙어주어 사용해야 하며 해당 경로가 포함되어 있으면 어디든 사용이 가능하다.
  • → 서버에 있는 특정한 경로에만 해당 Cookie를 사용하게 만들어 준다.
  • secure→ 이 Cookie는 HTTP에 SSL 보안 연결을 사용할 때만 사용한다.
  • → 유일하게 key=value 형태를 띄지 않는다.

Version 1 (RFC 2965) Cookie

• 폐기되어 더이상 지원하지 않음
• Set-Cookie2와 Cookie2 헤더를 소개하며, Version 0 과도 호환이 가능하다.
• 특징
• 쿠키마다 그 목적을 설명하는 설명문이 있다.
• 생명주기와 상관없이 브라우저가 닫히면 파기하도록 만들 수 있다.
• 파기 날짜를 절대 날짜 값이 아닌 초단위 상대값으로 쿠키생명주기를 결정할 수 있는 Max-Age를 사용한다.
• Domain, Path 뿐 아니라 Port로도 쿠키를 제어 할 수 있다.
• Domain, Path, Port 필터가 있으면 Cookie 헤더에 담겨 되돌려 보낸다.
• 호환되는 버전 번호
• 사용자 이름과 추가적인 키워드를 구별하기 위해 Cookie 헤더에 $ 접두어가 있다.

쿠키와 캐싱

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

캐시되지 말아야 할 문서가 있다면 표시하라!!

• Cache-Control
  • 해당 헤더를 통해 Cache를 Control할 수 있다.
  • no-cache=”Set-Cookie”를 기술하여 해당 헤더를 제외하고 캐시를 하도록 컨트롤 한다.
  • Cache를 해도 되는 문서에 Cache-Control: public을 사용하면 웹의 대역폭을 더 절약시켜준다.

Set-Cache 헤더를 캐시 하는 것에 유의하라!!

• 같은 Set-Cookie 헤더를 여러 사용자에게 보내게 되면, 사용자 추적에 실패할 것이기 때문이다.
• 어떤 Cache는 응답을 저장하기 전에 Set-Cookie 헤더를 제거하기 때문에 그 캐시 데이터를 받는 클라이언트는 Set-Cookie 헤더 정보가 없는 데이터를 받게 되어 문제가 발생할 수 있다.
• → Cache-Controll: must-revaildate, max-age=0 헤더를 추가하여 위 문제를 해결 할 수 있다.
• 더 보수적인 Cache는 Set-Cookie헤더를 가지고 있는 응답은 캐시를 하지 않을 수도 있다.
• 어떤 Cache는 Set-Cookie가 있는 이미지는 캐시를 하지만, 텍스트는 캐시하지 않는다.

---

Cookie, 보안 그리고 개인정보

• Cookie는 사용하지 않도록 비활성화 할수도 있으며, 로그 분석 같은 다른방법으로 대체하는 것도 가능한데, 그 자체가 보안상으로 엄청나게 위험한 것은 아니다.
• 쿠키에 대한 부정적인 여론이 많지만, 제공하는 개인정보를 누가 받는지 명확히 알고 사이트의 개인정보 정책에만 유의한다면, 쿠키에 관련한 위험성보다 세션 조작이나 트랜잭션상의 편리함이 더 크다.