HTTP 완벽 가이드 3부 - 식별, 인가, 보안

HTTP 완벽 가이드 시리즈를 정리한 내용입니다.

11장 클라이언트 식별과 쿠키

11.1 개별 접촉

• HTTP는 익명이고 무상태(Stateless)이다.
• 서버는 사용자를 식별하거나 연속적인 요청을 추적하기 위해 약간의 정보를 이용할 수 있다.
• 웹 사이트는 개인화된 서비스를 제공하고자 한다.
  • 개별 인사: 온라인 쇼핑이 개인에게 맞춰져 있는 것처럼 느끼게 하려고 특화된 메세지나 페이지를 만든다.
  • 사용자 맞춤 추천: 고객의 흥미를 학습해서 좋아할법한 제품을 추천하거나, 기념일 등에 특별한 제품을 제시한다.
  • 저장된 사용자 정보: 복잡한 주소, 신용카드 정보 등을 저장한다.
  • 세션 추적: 무상태 속에서도 사용자와 사이트가 상호작용할 수 있게 상태를 남긴다.(장바구니 등)
• 다음과 같은 기술을 사용한다.
  • 사용자 식별 관련 정보를 전달하는 HTTP헤더들
  • 클라이언트 IP 주소 추적으로 알아낸 IP주소로 사용자를 식별
  • 사용자 로그인 인증을 통한 사용자 식별
  • URL에 식별자를 포함하는 기술인 뚱뚱한 URL
  • 식별 정보를 지소개서 유지하는 강력하면서도 효율적인 기술인 쿠키

11.2 HTTP 헤더

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

• From
  • 사용자의 이메일 주소를 포함
  • 이상적으로는 각 사용자가 다른 이메일을 사용
  • 악의적인 서버가 이메일 주소를 수집할 수 있어 브라우저는 From 헤더를 잘 보내지 않음
• User-Agent
  • 사용자가 쓰고 있는 브라우저의 이름과 버전 정보, 운영체제 정보 등을 기술
  • 사용자를 식별해내는데에는 별로 도움되지 않음
• Referer
  • 사용자가 현재 페이지로 유입하게 한 웹페이지의 URL을 가리킴
  • 사용자의 웹 사용 행태나 사용자의 취향을 더 잘 파악할 수 있음

11.3 클라이언트 IP 주소

• IP주소로 사용자를 식별하려면 사용자가 확실한 IP주소를 가지고 이쏙, 절대 바뀌지 않고, 웹 서버가 요청마다 클라이언트 IP를 알 수 있어야 한다.
• 많은 약점을 가진다.
  • 한 컴퓨터를 여러 사용자가 사용할 수 있다.
  • ISP는 사용자에게 동적으로 IP주소를 할당하므로 매번 다를 수 있다.
  • 많은 사용자가 네트워크 주소 변환 방화벽을 사용한다. 클라이언트 IP 주소는 숨기고 하나의 방화벽 IP 주소를 사용하게 된다.
  • HTTP 프록시는 원 서버에 새로운 TCP연결을 하므로, 웹 서버는 클라이언트의 IP 주소 대신 프록시 서버의 IP 주소를 본다.

11.4 사용자 로그인

• 웹 서버는 사용자 이름과 비밀번호로 인증(로그인)할 것을 요구해서 사용자에게 명시적으로 식별 요청을 할 수 있다.
  • WWW-Authenticate와 Authorization헤더를 사용한다.
  • 12장에서 자세히 다룬다.

11.5 뚱뚱한 URL

• 사용자의 URL마다 버전을 기술하여 사용자를 식별한다.
• 사용자의 상태 정보를 포함하고 있는 URL을 뚱뚱한 URL이라고 한다.
• 사용자가 웹 사이트에 처음 방문하면 유일한 ID가 생성되고, 그 값은 모든 하이퍼링크에 추가되어 작동한다.
• 여러 심각한 문제가 있다.
  • 못생긴 URL: 브라우저에 보이는 뚱뚱한 URL은 새로운 사용자들에게 혼란을 준다.
  • 공유하지 못하는 URL: URL을 누군가에게 공유하면 개인 정보를 공유하는 것과 같다.
  • 캐시를 사용할 수 없음: URL이 달라지기 때문에 기존 캐시에 접근할 수 없다.
  • 서버 부하 가중: 서버는 뚱뚱한 URL에 해당하는 HTML 페이지를 다시 그려야 한다.
  • 이탈: 사용자가 의도치않게 URL 세션에서 이탈하면 기존 진척상황들이 초기화된다.
  • 세션 간 지속성의 부재: 특정 뚱뚱한 URL을 사용자가 북마킹하지 않는 이상, 로그아웃하면 모든 정보를 잃는다.

11.6 쿠키

• 사용자를 식별하고 세션을 유지하는 방식 중에서 가장 널리 사용된다.

11.6.1 쿠키의 타입

• 세션 쿠키: 설정과 신호 사항들을 저장하는 임시 쿠키. 브라우저를 닫으면 삭제된다.
• 지속 쿠키: 디스크에 저장되어 브라우저를 닫거나 컴퓨터를 재시작하더라도 남아있다.

11.6.2 쿠키는 어떻게 동작하는가

• 쿠키는 서버가 사용자에게 붙이는 스티커와 같다.
• Set-Cookie 혹은 Set-Cookie2같은 헤더로 임의의 이름=값형태의 리스트를 사용자에게 전달한다.
• 브라우저는 해당 헤더에 있는 쿠키 컨텐츠를 브라우저 쿠키 데이터베이스에 저장한다.
• 미래에 같은 사이트를 방문하면, 브라우저는 서버가 할당했던 쿠키를 Cookie 요청 헤더에 기술해 전송한다.

11.6.3 쿠키 상자: 클라이언트 측 상태

• 브라우저는 서버 관련 정보를 저장하고, 사용자가 서버에 접근할 때마다 정보를 함께 전송한다.
• 구글 크롬 쿠키의 주요 필드
  • creation_utc: 쿠키가 생성된 시점을 알려준다. Jan 1, 1070 00:00:00 GTM으로 부터 초단위로 기술한다.
  • host_key: 쿠키의 도메인
  • name: 쿠키의 이름
  • value: 쿠키의 값
  • path: 쿠키와 관련된 도메인이에 있는 경로
  • expire_utc: 쿠키의 파기 시점을 알려준다. creation_utc와 같은 단위를 사용
  • secure: 이 쿠키를 SSL 커넥션일 경우에만 보낼지를 가리킨다.

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

• 브라우저는 수많은 쿠키를 가지지만, 모든 사이트에 전부 보내지는 않는다.
  • 쿠키를 모두 전달하려면 성능이 저하된다.
  • 특정 서버에서만 의미있기 때문에, 다른 사이트에서는 무의미하다.
  • 신뢰하지 않는 사이트에 제공하면 잠재적인 개인정보 문제를 일으키는 것이다.
• 브라우저는 쿠키를 생성한 서버에게만 쿠키를 전달한다.

쿠키 Domain 속성

Set-cookie: user=”mary17”; domain=”airtravelbargains.com”

• Set-Cookie응답 헤더에 Domain 속성을 기술해서 어떤 사이트가 그 쿠키를 읽을 수 있는지 제어할 수 있다.
• 예시의 경우 www.airtravelbargains.com이나 specials.airtravelbargains.com과 같은 사이트를 방문한다면 Cookie: user="mary17"가 항상 적용된다.

쿠키 Path 속성

Set-cookie: pref=compact; domain=”airtravelbargains.com”; path=/autos/

• URL경로의 앞부분을 가리키는 Path 속성을 기술해서 해당 경로에 속하는 페이지에만 쿠키를 전달한다.
• 사용자가 ~.com/specials.html에 접근하면 user="mary17"만을, ~.com/autos/cheapo;/index.html로 접근하면 pref=compact까지 전송하게 될 것이다.

11.6.5 쿠키 구성요소

• Version 0 쿠키(넷스케이프 쿠키), Version 1 쿠키(‘RFC 2965’)가 있다.
• Version 1 쿠키는 널리 사용되지 않는다.

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

Set-Cookie: name=value [; expires=date] [; path=path] [; domain=domain] [; secure]
Cookie: name1=value1 [; name2=value2] …

11.6.9 쿠키와 캐싱

• 쿠키 트랜잭션과 관련된 문서를 캐싱하는 것은 주의해야 한다.
• 이전 사용자의 쿠키가 다른 사용자에게 할당되거나, 개인 정보가 노출될 수도 있다.
• 캐시되지 말아야 할 문서가 있다면 표시하라
  • Cache-Control: no-cache="Set-Cookie를 기술해서 명확히 표시
• Set-Cookie 헤더를 캐시하는 것에 유의하라
  • 같은 Set-Cookie 헤더를 여러 사용자에게 보내면 사용자 추적에 실패할 것이다.
  • 어떤 캐시는 Set-Cookie 헤더를 제거하기 때문에 클라이언트는 헤더 정보가 없는 데이터를 받게될 수도 있다.
  • Cache-Control: must-revalidate, max-age=0을 통해서 캐시에 대한 재검사가 항상 일어나게 할 수 있다.
• Cookie 헤더를 가지고 있는 요청을 주의하라
  • Cookie 헤더가 온다면, 개인정보를 담고 있을 수도 있다.

12장 기본 인증

• 서버는 사용자가 누구인지 식별하고 데이터에 대해 각기 다른 접근 권한을 부여해야 한다.

12.1 인증

12.1.1 HTTP의 인증요구/응답 프레임워크

1. 클라이언트는 서버에게 데이터를 요청한다.
2. 서버는 클라이언트에게 인증을 요구한다.
3. 클라이언트는 서버에게 인증정보를 전송한다.
4. 서버는 클라이언트에게 데이터를 응답한다.

12.1.2 인증 프로토콜과 헤더

단계	헤더	설명	메서드/상태
요청		첫 번째 요청에는 인증 정보가 없다.	GET
인증 요구	WWW-Authenticate	서버는 사용자에게 401 상태 정보와 함께 요청을 반려한다. 사용자 이름과 비밀번호를 요구한다.	401 Unauthorized
인증	Authorization	인증 알고리즘과 사용자 이름과 비밀번호를 기술한 Authorization 헤더를 보낸다.	GET
성공	Authentication-Info	인증 정보가 정확하면 문서와 함께 응답한다. 선택적인 헤더인 Authentication-Info에 추가 정보를 기술할 수 있다.	200 OK

12.1.3 보안 영역

• 웹 서버는 기밀문서를 보안 영역(realm) 그룹으로 나눈다. 보안 영역은 저마다 다른 사용자 권한을 요구한다.

12.2 기본 인증

• 웹 서버는 클라이언트의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다.
• 인증요구 - WWW-Authenticate: realm은 요청 받은 문서 집합의 이름을 따옴표로 감싼 것으로, 사용자는 이 정보를 보고 어떤 비밀번호를 사용해야하는지 알 수 있다.
• 응답 - Authorization: 사용자 이름과 비밀번호를 콜론으로 잇고 base-64로 인코딩해서 노출되지 않게 한다.

12.2.2 Base-64 사용자 이름/비밀번호 인코딩

• HTTP 기본 인증은 사용자 이름과 비밀번호를 콜론으로 이어서 합치고, base-64 인코딩 메서드를 사용해 인코딩 한다.
• 바이너리, 텍스트, 국제 문자 데이터 문자열을 받아서 전송할 수 있게 알파벳으로 변환한다.

12.2.3 프록시 인증

• 중개 프록시 서버를 통해 인증할 수도 있다.
• 어떤 회사는 프록시 서버를 거치게 하여 사용자를 인증한다.
• 접근 정책을 중앙에서 관리할 수 있다.
• 비인증 상태 코드는 401 대신 407 사용
• WWW-Authenticate 대신 Proxy-Authenticate, Authorization 대신 Proxy-Authorization, Authenticate-Info 대신 Proxy-Authentication-Info 사용

12.3 기본 인증의 보안 결함

1. 사용자 이름과 비밀번호를 쉽게 디코딩할 수 있는 형식으로 전송한다. base-64로 인코딩된 비밀번호를 사실 그냥 그대로 보내는 것과 다름없다.
2. 보안 비밀번호가 복잡하게 인코딩되어있다고 하더라도, 악의적으로 이를 캡쳐하여 그대로 사용할 수 있다.
3. 비록 이런 탈취가 해당 사이트에서는 치명적이지 않더라도, 같은 아이디 비밀번호를 사용하는 타 사이트에 악용될 수 있다.
4. 본래 의도를 바꿔버리는 프록시나 중개자가 개입할 수 있다.
5. 가짜 서버의 위장에 취약하다. 진짜 사이트라고 믿게끔 하고 비밀번호를 요구할 수 있다.