쿠키의 구조와 보안 취약성

핵심 정리

쿠키는 HTTP가 요청 사이의 상태를 기억하지 않는 무상태성을 보완하기 위해 쓰이는 정보다. 같은 사이트를 여러 번 찾아가도 서버는 앞선 요청을 자동으로 떠올리지 못하므로, 로그인 상태나 화면 설정 같은 연속성은 쿠키 같은 별도 수단이 있어야 이어진다. 쇼핑몰 장바구니 등 상태 유지 기능에는 쿠키 정보가 이용된다.

쿠키의 골격은 전달 경로에서 시작된다. 쿠키는 응답 메시지의 상태 라인이 아니라 Set-Cookie 헤더로 전달된다. 응답으로 설정된 쿠키는 클라이언트가 다시 요청할 때 HTTP 요청의 헤더 라인 Cookie에 실려 서버로 전송된다. 즉 쿠키는 설정과 전송이라는 두 번의 헤더 교환을 거쳐 한 번 정해진 값이 여러 요청에서 되풀이되는 구조다.

효과 면에서 쿠키는 서버가 기억할 상태를 클라이언트가 보관하는 방식이다. 서버는 쿠키를 통해 요청마다 같은 상대를 다시 알아볼 수 있으므로 방문의 흐름을 이어 갈 수 있다. 쿠키에 포함되는 내용은 웹 응용프로그램 개발자가 정할 수 있다.

한계도 분명하다. 쿠키에 담긴 정보가 사용자 모르게 서버로 전송되어 개인정보 피해가 생길 수 있다. 쿠키의 보안 문제는 전송되는 정보의 노출에만 그치지 않고 쿠키 값을 바꾸는 행위로도 이어진다. 쿠키 값을 바꾸는 행위가 어떤 공격에 해당하는지는 뒤의 헷갈리는 항목에서 따로 본다.

시험 관점에서 쿠키의 개념은 세 가지 축으로 정리하면 편하다. 하나는 무엇을 위해 쓰이는지이고, 다른 하나는 어느 헤더로 오가는지이며, 마지막은 그 값이 어떤 위험에 놓이는지이다. 이 세 축을 따라 읽으면 선지가 설정 단계를 묻는지, 전송 단계를 묻는지, 보안 위협을 묻는지를 빠르게 가를 수 있다.

자세히

전달 방향과 헤더

쿠키는 두 개의 헤더로 나뉘어 오간다. Set-Cookie는 서버가 응답 헤더로 쿠키를 설정할 때 쓰이며, 요청 라인에는 들어가지 않는다. Cookie는 이전에 서버가 준 쿠키 정보를 요청에 실어 서버로 돌려보내는 요청 헤더다. 브라우저는 요청 메시지의 Cookie 헤더에 저장된 쿠키를 담아 서버로 전달한다.

두 헤더는 같은 쿠키를 다루지만 메시지의 종류와 흐름의 방향이 모두 반대다. 그래서 쿠키 문제를 볼 때는 먼저 그 값이 응답에서 설정되는 단계인지, 요청에서 전송되는 단계인지부터 나누는 것이 정확하다. 요청 라인과 응답 헤더를 혼동하면 쿠키가 서버에 도달하는 경로를 잘못 짚게 된다.

로그인 뒤 게시판과 설정 화면을 차례로 열어도 로그인 상태가 이어지는 장면을 떠올리면 이 구조가 잡힌다. 이런 장면을 풀 때는 값을 받은 요청이 어디였는지보다, 값이 어느 요청에 실려 갔는지를 기준으로 보는 것이 정확하다. 응답 헤더와 요청 헤더를 같은 자리로 보면 장면마다 어느 쪽 메시지가 쿠키를 나르는지를 놓치게 된다.

값의 생성과 저장

쿠키의 값은 서버가 정한다. 서버는 클라이언트에 관해 수집한 정보나 세션 식별자로 쿠키 값을 만들어 Set-Cookie로 보낸다. 브라우저는 Set-Cookie 지시에 따라 쿠키를 클라이언트 측 저장소에 기록한다.

세션 식별자를 값으로 담으면 서버는 다음 요청에서 같은 클라이언트를 알아볼 수 있다. 이때 쿠키 값은 사용자가 누구인지를 서버에 알려 주는 표지 역할을 한다. 그래서 그 값이 다른 사람에게 노출되면 서버는 요청자를 제대로 구별하기 어려워진다.

장바구니 장면에서도 같은 원리가 적용된다. 사용자가 상품을 담으면 서버는 그 흐름을 쿠키 값과 연결해 두고, 다음 페이지를 열 때 그 값을 받아 같은 흐름을 이어 간다. 이때 쿠키 값이 가리키는 상태가 노출되면 다른 사람이 같은 흐름을 따라갈 수 있으므로, 값 자체의 보호가 중요하다.

정보 노출과 추적

쿠키를 이용하면 사용자가 특정 사이트를 방문했는지 확인할 수 있다. 쿠키는 웹사이트 이용 편의를 위해 만들어졌지만, 많은 웹사이트가 이를 이용해 사용자 정보를 수집한다.