3부. 식별, 인가, 보안

10장. HTTP2.0 / 12장. 기본 인증 환일님 블로그
13장. 다이제스트 인증 준수님 노션

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

웹 서버는 동시에 서로 다른 수천 개의 클라이언트들과 통신한다. 따라서 서버들은 클라이언트로부터 받은 요청을 처리하는 것 뿐만 아니라, 클라이언트를 추적할 수도 있어야 한다. 이 장에서는 서버가 통신 대상을 식별하는데에 사용하는 기술을 알아본다.

11.1 개별 접촉

HTTP 트랜잭션은 상태가 없고(stateless), 각 요청과 응답이 독립적으로 일어난다. 따라서 많은 웹사이트에서 사용자가 사이트와 상호작용할 수 있도록 사용자의 상태를 남긴다. 이렇게 상태를 유지하기 위해서는 HTTP 트랜잭션을 식별할 방법이 필요하다. 이 장에서 알아볼 내용은 다음과 같다.

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

11.2 HTTP 헤더

사용자에 대한 정보를 제공하는 가장 일반적인 HTTP 요청 헤더는 아래와 같다.

• From : 사용자의 이메일 주소
• User-Agent : 사용자의 브라우저 정보
• Referer : 사용자가 현재 링크를 타고 온 근원 페이지
• Authorization : 사용자 이름과 비밀번호(인증 정보)
• Client-ip : 클라이언트의 IP 주소
• X-Forwarded-For : 클라이언트의 IP 주소
• Cookie : 서버가 생성한 ID 라벨

From 헤더는 이메일 주소를 담지만 악의적으로 메일 주소를 모아서 스팸 메일을 보낼 수 있기 때문에 최근에는 브라우저에서 From 헤더로 이메일 주소를 보내지 않는다.

User-Agent 는 특정 브라우저에서 제대로 동작하도록 속성에 맞춰 콘텐츠를 최적화하는 데 유용할 수 있으나, 사용자를 식별하는 데에는 무리가 있다.

Referer 헤더를 통해서는 사용자의 웹 사용 행태나 취향 등을 파악할 수 있다.

11.3 클라이언트 IP 주소

초기 웹 개발자들은 사용자 식별에 클라이언트 IP 주소를 사용하려고 했다. 하지만 다음과 같은 단점이 있었다.

• 클라이언트 IP는 사용자가 아닌 사용하는 컴퓨터를 가리킨다. 따라서 여러 사람이 한 대의 컴퓨터를 사용한다면 그들을 식별할 수 없다.
• 많은 인터넷 서비스 제공자(ISP)는 사용자가 로그인하면 동적으로 IP 주소를 할당한다. 로그인 시간에 따라 매번 다른 IP 주소를 할당받기 때문에 식별이 불가능하다,
• 많은 사용자들이 네트워크 주소 변환(NAT) 방화벽을 통해 인터넷을 사용한다. 이 방화벽이 실제 IP 주소를 숨기고 방화벽 IP 주소로 변환한다.
• 프록시나 게이트웨이가 있는 경우, 서버는 클라이언트가 아닌 프록시 혹은 게이트웨이와 통신한다. 따라서 서버가 보는 IP 주소 역시 클라이언트의 것이 아니다. 이 문제를 해결하기 위해 Client-ip, X-Forwared-For 확장 헤더를 사용할 수 있다.

11.4 사용자 로그인

IP 주소로 사용자를 식별하려는 수동적인 방법보다는 인증 요구를 통해 식별 요청을 할 수 있다. HTTP 는 WWW-Authenticate 와 Authentication 헤더를 사용해 사용자 정보를 전달하는 자체적인 체계를 가지고 있다.

로그인 후에는 사용자 식별정보 토큰을 Authorization 헤더에 담아 한 세션이 진행되는 동안 식별을 유지한다.

11.5 뚱뚱한(fat) URL

사용자에게 할당된 식별번호를 URL 경로의 처음이나 끝에 추가하여 확장한다. 사이트 내부를 돌아다니면, 서버가 URL 에 있는 상태 정보를 유지하는 하이퍼링크를 동적으로 생성한다.

...
<a href="/exec/obidos/tg/browse/-/229220/ref=gr_gifts/002-1145265-8016838">All Gifts</a><br>
<a href="/exec/obidos/wishlist/ref=gr_pl1_/002-1145265-8016838">Wish List</a><br>
...
<a href="http://s1.amazon.com/exec/varzea/tg/armed-forces/-//ref=gr_af_/002-1145265-8016838">Salute Our Troops</a><br>
<a href="/exec/obidos/tg/browse/-/749188/ref=gr_p4_/002-1145265-8016838">Free Shipping</a><br>
<a href="/exec/obidos/tg/browse/-/468532/ref=gr_returns/002-1145265-8016838">Easy Returns</a>
...

위의 예제는 Amazon 에서 뚱뚱한 URL을 사용하는 경우이다. URL 끝에 사용자 식별 정보인 002-1145265-8016838 가 계속해서 따라 다니는 것을 볼 수 있다.

사용자가 처음 방문하면 고유 ID가 생성되고, 그 값을 서버가 변환하여 URL 에 추가하는 동시에 사용자를 뚱뚱한 URL 로 리다이렉트 시킨다. 서버가 뚱뚱한 URL 요청을 받으면, 사용자와 관련된 정보를 찾아서 모든 하이퍼링크를 뚱뚱한 URL로 바꾼다. 이러한 방식으로 사용자를 식별할 수 있지만 이 기술에도 문제점이 있다.

• 뚱뚱한 URL은 사용자들에게 혼란을 준다.
• URL을 다른 사람과 공유하면 개인 정보를 공유하게 된다.
• URL이 달라지므로 기존 캐시에 접근할 수 없다.
• 뚱뚱한 URL에 해당하는 HTML 페이지를 다시 그려야 하는 서버 부담이 있다.
• 사용자가 링크를 타고 다른 사이트로 이동하는 등 뚱뚱한 URL 세션에서 이탈하기 쉽다. 사용자가 이탈하면, 그 동안의 사항들(장바구니 등)이 초기화 된다.
• 특정 뚱뚱한 URL을 북마킹하지 않으면, 로그아웃했을 때 모든 정보를 잃게 된다.

11.6 쿠키

쿠키는 사용자를 식별하고 세션을 유지하는 방식 중에서 현재까지 가장 널리 사용되는 방식이다. 넷스케이프가 최초로 개발하였으며, 지금은 모든 브라우저에서 지원한다.
쿠키는 캐시와 충돌할 수 있어서, 대부분의 캐시나 브라우저는 쿠키에 있는 내용물을 캐싱하지 않는다.

11.6.1 쿠키의 타입

쿠키는 크게 세션 쿠키(session cookie)와 지속 쿠키(consistent cookie) 두 가지 타입으로 나뉜다.

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

세션 쿠키와 지속 쿠키의 차이점은 파기 시점이다. Discard 파라미터가 설정되어 있거나, Expires 혹은 Max-Age 파라미터가 없으면 세션 쿠키가 된다.

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

쿠키는 서버가 사용자에게 "안녕, 내 이름은 ~" 라고 적어서 붙이는 스티커와 같다. 사용자가 웹 사이트에 방문하면, 웹 사이트는 서버가 사용자에게 붙인 스티커를 읽을 수 있다.

사용자가 처음 웹 사이트에 접속했을 때, 서버는 사용자에 대해 아무것도 알지 못한다. 해당 사용자가 다시 돌아왔을 때, 식별하기 위한 목적으로 유일한 식별값을 쿠키에 할당한다. HTTP 응답 헤더에 Set-Cookie 혹은 Set-Cookie2(확장 헤더)에 기술되어 전달한다.

쿠키에는 어떠한 정보도 포함될 수 있지만, 사용자 추적 용도로 생성한 단순 식별 번호만 포함하기도 한다. 많은 웹 서버가 아래와 같이 여러 정보를 쿠키에 포함시키려고 한다.

Cookie: name="David"; phone="555-1212"

브라우저는 서버로부터 헤더에 담겨온 쿠키 콘텐츠를 브라우저 쿠키 데이터베이스에 저장한다. 사용자가 같은 사이트를 방문하면, 서버가 할당한 해당 쿠키를 Cookie 요청 헤더에 기술하여 전송한다.

이미지 출처

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

쿠키의 사용 방법은 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때마다 그 정보를 함께 전송하는 것이다. 따라서 브라우저는 쿠키 정보를 저장할 책임이 있고, 이를 클라이언트 측 상태 라고 한다. 쿠키 명세에서는 HTTP 상태 관리 체계(HTTP State Management Mechanism) 이라고 지칭한다.

각 브라우저는 각기 다른 방식으로 쿠키를 저장한다. 구글 크롬은 SQLite 파일에 쿠키를 저장한다. 각 PC의 브라우저마다 이를 직접 확인할 수 있다.

경로 : Users/pc이름/Library/Application Support/Google/Chrome/Default
$ sqlite3 Cookies
$ .headers on
$ .mode column
$ .tables(table 확인)
$ select * from cookies

참고 사이트

• creation_utc : 쿠키가 생성된 시점을 알려준다. Jan 1, 1970 00:00:00 GMT로부터 생성된 시간을 초 단위로 기술한다.
• host_key : 쿠키의 도메인
• name : 쿠키 이름
• value : 쿠키 값 --> 작년부터 구글에서 value를 암호화하기 시작했기 때문에 캡쳐본에는 짤렸지만 encrypted_value 에 암호화되어 (BLOB) 으로 나타난다.
• path : 쿠키와 관련된 도메인 경로
• expire_utc : Jan 1, 1970 00:00:00 GMT로부터 파기될 시간을 초 단위로 기술한다.
• secure : 쿠키를 SSL 커넥션일 경우에만 보낼지 여부를 나타낸다.

11.6.4 사이트마다 다른 쿠키들

브라우저는 사이트마다 다른 쿠키를 받아서 저장하지만, 해당 사이트에 접속할 때 가지고 있는 모든 쿠키를 전송하지 않는다. 쿠키를 생성한 서버에만 해당 쿠키에 담긴 정보를 제공한다.

많은 웹 사이트가 온라인 광고를 관리하는 업체들과 계약을 맺는다. 온라인 광고는 마치 웹 사이트의 일부처럼 제작되고, 지속 쿠키를 만든다. 같은 광고사와 계약을 맺은 서로 다른 사이트를 사용자가 방문하면, 이미 앞서 만든 지속 쿠키를 광고사 서버로 전송한다. 그 이유는 지속 쿠키의 도메인이 같기 때문이다. 그리고 광고사는 이러한 기술에 Referer 헤더를 접목하여 사용자의 프로필과 웹 사이트 방문 정보에 대한 방대한 데이터를 구축할 수 있다.
그러나 최신 브라우저는 개인정보 설정 기능을 통해 이러한 광고사의 쿠키 사용 방식에 제약을 가하도록 하고 있다.

쿠키 Domain 속성
서버는 쿠키를 생성할 때, Set-Cookie 응답 헤더에 Domain 속성을 기술하여 어떤 사이트가 해당 쿠키를 읽을 수 있는지를 파악할 수 있다.

Set-Cookie: user="mary17"; domain="airtravel.com"

위와 같은 경우, .airtravel.com 도메인을 가진 모든 사이트에 해당 쿠키를 전달한다는 뜻이다. 따라서 www.airtravel.com 나 special.airtravel.com 같이 .airtravel.com 로 끝나는 사이트를 방문하면 브라우저는 해당 쿠키를 서버에 전송한다.

Cookie: user="mary17"

쿠키 Path 속성
웹 사이트 내에서 일부에만 쿠키를 적용할 수도 있다. URL 경로의 앞부분을 가리키는 Path 속성을 기술하여, 해당 경로에 속하는 페이지에만 쿠키를 전달한다.

Set-Cookie: pref=compact; domain="airtravel.com"; path=/autos/

위와 같은 경우, 만약 사용자가 www.airtravel.com/specials.html 에 접근하면 다음의 쿠키만 얻게 된다.

Cookie: user="mary17"

그러나 www.airtravel.com/autos/suv/index.html 로 접근하게 되면 쿠키는 다음과 같다.

Cookie: user="mary17"
Cookie: pref="compact"

추가된 value 값을 얻을 수 있게 된다.

11.6.5 쿠키 구성요소

현재 사용되는 쿠키 명세에는 Version 0 쿠키(흔히 '넷스케이프 쿠키' 라고 불림)와 Version 1 쿠키('RFC 2956')가 있다. Version 1 쿠키는 Version 0 쿠키의 확장으로 많이 쓰이지는 않는다.

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

최초의 쿠키 명세는 넷스케이프가 정의했다.

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

Set-Cookie 헤더는 쿠키의 이름과 값을 가져야 한다. 다른 속성 필드들은 아래와 같다.

• Expires : 선택적 속성. 쿠키의 생명주기를 가리키는 날짜 문자열. 파기 일자가 되면 삭제되며, 전달하지 않는다. 날짜 형식은 요일, DD-MM-YY HH:MM:SS GMT 이다. 타임존은 GMT 만 사용할 수 있다. 날짜 요소 사이에는 반드시 (-)로 연결되어야 한다. 쿠키에 Expires 가 명시되지 않으면 해당 쿠키는 사용자의 세션이 끝날 때 파기된다.
• Domain : 선택적 속성. 해당 도메인을 사용하는 서버로만 쿠키를 전송한다. 도메인이 명시되어 있지 않은 경우에는 Set-Cookie 응답을 생성한 서버의 호스트 명을 기본값으로 한다.
• Path : 선택적 속성. 서버 내의 특정 문서에만 쿠키를 보낼 수 있다. URL 앞부분과 일치하면 쿠키를 전달하는데 예를 들면, /foo 경로는 /foobar와 /foo/bar.html 모두 해당된다. / 경로는 도메인 내의 모든 경로에 해당된다. 경로가 명시되지 않으면, Set-Cookie 응답을 전달하는 경로가 사용된다.
• Secure : 선택적 속성. HTTP가 SSL 보안 연결을 사용할 때만 쿠키를 전송한다.

클라이언트가 서버에 요청을 보낼 때는 Domain, Path, Secure 속성들이 현재 사이트와 일치하면서 아직 파기되지 않은 쿠키를 보낸다. 모든 쿠키는 Cookie 헤더에 이어 보낸다.

Cookie: session-id=002-112-2343824; session-id-time=1007884800

11.6.7 Version 1(RFC2965) 쿠키

RFC2965는 폐기되어 더 이상 지원되지 않음.
자세한 내용은 책 312p ~ 316p 참조

11.6.8 쿠키와 세션 추적

쿠키의 목적은 사용자를 추적하는 것이고, 전자상거래 웹 사이트의 경우에는 사용자의 장바구니를 유지하기 위해 세션 쿠키를 사용한다.

미국 아마존에서의 트랜잭션을 예로 들면 아래와 같다.

• a : 브라우저가 아마존의 루트 페이지에 요청을 보낸다.
• b : 서버는 클라이언트를 전자상거래 소프트웨어 URL로 리다이렉트 시킨다.
• c : 클라이언트는 리다이렉트 URL로 요청을 보낸다.
• d : 서버는 응답에 두 개의 세션 쿠키를 기술하고 사용자를 다른 URL로 리다이렉트 시킨다.(뚱뚱한 URL)
• e : 클라이언트는 새로운 URL 에 앞서 받은 쿠키를 포함하여 요청을 보낸다.
• f : 서버는 home.html 페이지로 리다이렉트시키면서 쿠키 두 개를 더 보낸다.
• g : 총 네 개의 쿠키를 담아 home.html 에 요청을 보낸다.
• h : 서버가 최종적으로 콘텐츠를 보낸다.

11.6.9 쿠키와 캐싱

쿠키는 캐싱에 주의해야 한다. 다른 사용자의 쿠키가 할당되거나 개인정보가 타인에게 노출될 수 있기 때문이다.

• 캐시되지 말아야 할 문서는 표시하라

Cache-Control: no-cache="Set-Cookie"

• Set-Cookie 헤더를 캐시 하는 것에 유의하라. 서버가 아래의 헤더를 캐시된 문서에 추가하여 요청마다 재검사한다.

Cache-Control: must-revalidate, max-age=0

• Cookie 헤더를 가지고 있는 요청을 주의하라. 보수적인 캐시는 Cookie 헤더를 가진 응답 문서를 캐시하지 않는다.

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

쿠키와 IP주소, Referer 헤더 등을 활용하면 사용자의 프로필과 사용 패턴에 대해 데이터를 수집할 수 있다. 쿠키에 대한 부정적인 여론이 많지만, 제공하는 정보를 누가 받는지 명확히 알고 개인정보 정책에만 유의하면 위험성보다는 편리함이 더 큰 기술이다.

1998년 미 재무성 컴퓨터 사고 자문단의 위험성 평가서 내용은 아래와 같다.

쿠키는 사용자의 웹 사이트 방문 이력이나 전달 받은 사용자 고유 식별값을 서버에 다시 보내주는 용도일 뿐이다. 대부분의 쿠키는 브라우저를 빠져나감과 동시에 제거되며, 지속 쿠키는 파기 시간 전까지만 디스크에 남는다. 쿠키 말고도 웹 로그 파일을 통해서 사용자의 브라우징 습관을 추적할 수 있으며, 쿠키는 다만 이를 편리하게 해줄 뿐이다.