[Node.js 교과서] #9. 쿠키와 세션 이해하기

쿠키와 세션 이해하기

클라이언트에서 보내는 요청에는 한 가지 큰 단점이 있다. 바로 누가 요청을 보내는지 모른다는 것이다. 물론 요청을 보내는 IP 주소나 브라우저의 정보를 받아올 수는 있다. 하지만 여러 컴퓨터가 공통으로 IP 주소를 가지거나, 한 컴퓨터를 여러 사람이 사용할 수도 있다.

그렇다면 로그인을 구현하면 되지 않느냐고 생각할 수도 있다. 정답이다. 하지만 로그인을 구현하려면 쿠키와 세션에 대해 알고 있어야 한다. 우리가 웹 사이트에 방문해서 로그인을 할 때 내부적으로는 쿠키와 세션ㅇ르 사용하고 있다. 로그인한 후에는 새로고침(새로운 요청)을 해도 로그아웃되지 않는 이유는 바로 클라이언트가 서버에서 우리가 누구인지를 지속적으로 알려주고 있기 때문이다.

우리가 누구인지 기억하기 위해서, 서버는 요청에 대한 응답을 할 때 쿠키라는 것을 같이 보낸다. 쿠키는 name=zerocho 같이 단순한 '키-값'의 쌍이다. 서버로부터 쿠키가 오면 웹 브라우저는 쿠키를 저장해두었다가 요청할 때마다 쿠키를 동봉해서 보내준다. 서버는 요청에 들어있는 쿠키를 읽어서 사용자가 누구인지 파악한다.

브라우저는 쿠키가 있다면 자동으로 동봉해서 보내주므로 따로 처리할 필요가 없다. 서버에서 브라우저로 쿠키를 보낼 때만 우리가 코드를 작성해서 처리하면 된다.

 

 

즉, 서버는 미리 클라이언트에 요청자를 추정할 만한 정보를 쿠키로 만들어 보내고, 그 다음부터는 클라이언트로부터 쿠키를 받아 요청자를 파악한다. 쿠키가 우리가 누구인지 추적하고 있는 것이다. 개인정보 유철 방지를 위해 쿠키를 주기적으로 지우라는 말이 바로 이러한 이유 때문이다.

쿠키는 요청과 응답의 헤더에 저장된다. 서버에서 직접 쿠키를 만들어 요청자의 브라우저에 넣어보자.

 

 

 

쿠키는 name=zerocho;year=1994처럼 문자열 형식으로 오므로 이를 { name: 'zerocho', year: 1994' }와 같이 객체로 바꾸는 함수 parseCookies를 직접 만들었다.

createServer 메서드의 콜백에서는 제일 먼저 req 객체에 담겨 있는 쿠키를 분석한다. 쿠키는 req.headers.cookie에 들어 있다. req.headers는 요청의 헤더를 의미한다. 

응답의 헤더에 쿠키를 기록해야 하므로 res.writeHead 메서드를 사용하였다. 첫 번째 인자로 200이라는 상태 코드를 넣어두었다. 200은 성공이라는 의미이다. 두 번째 인자로는 헤더의 내용을 입력한다. Set-Cookie는 브라우저한테 다음과 같은 쿠키를 저장하라는 의미이다. 실제로 응답을 받은 브라우저는 mycookie=test라는 쿠키를 저장한다.

 

 

localhost:8082에 접속한다. req.url과 cookies 변수에 대한 정보를 로깅하도록 했다. req.url은 주소의 path와 search 부분을 알려준다.

 

 

만약 실행 결과가 위와 다르다면 브라우저의 쿠키를 모두 제거한 후에 다시 실행해야 한다. 다른 사이트나 프로그램이 미리 쿠키를 넣어두었을 수도 있기 때문이다.

 

요청은 분명 한 번만 보냈는데 /favicon.ico와 함께 두 개가 기록되어 있다. 첫 번째 요청('/') 에서는 쿠키에 대한 정보가 없다고 나오고, 두 번째 요청('/favicon.ico')에서는 { mycookie: 'test' }가 기록되었다.

파비콘이란 다음과 같이 웹 사이트 탭에 보이는 이미지를 뜻한다.

 

 

브라우저는 파비콘이 뭔지 HTML에서 유추할 수 없으면 서버에 파비콘 정보에 대한 요청을 보낸다. 현재 예제에서 HTML에 파비콘에 대한 정보를 넣어두지 않았으므로 브라우저가 추가로 /favicon.ico를 요청한 것이다.

요청 두 개를 통해 서버가 제대로 쿠키를 심어 주었음을 확인할 수 있다. 첫 번째 요청(/)을 보내기 전에는 브라우저가 어떠한 쿠키 정보도 가지고 있지 않았다. 서버는 응답의 헤더에 mycookie=test라는 쿠키를 심으라고 브라우저에게 명령했다. 따라서 브라우저는 쿠키를 심었고, 두 번째 요청(/favicon.ico)의 헤더에 쿠키가 들어있음을 확인할 수 있다.

 

아직까지는 단순한 쿠키만 심었을 뿐, 그 쿠키가 나인지를 식별해주지 못하고 있다. 다음 예제에서 식별하는 방법에 대해 알아보자.

 

 

 

쿠키를 설정할 때 만료 시간(Expires)과 HttpOnly, Path 같은 옵션을 부여했다. 쿠키는 설정할 때 각종 옵션들을 넣을 수 있다. 옵션 간에는 세미콜론으로 구분하면 된다.

• 쿠키명=쿠키값 : 기본적인 쿠키의 값이다. mycookie=test 또는 naem=zerocho 같이 설정한다.
• Expires=날짜 : 만료 기한이다. 이 기한이 지나면 쿠키가 제거된다. 기본값은 클라이언트가 종료될 때까지이다.
• Max-age=초 : Expires와 비슷하지만 날짜 대신 초를 입력할 수 있다. 해당 초가 지나면 쿠키가 제거된다. Expires보다 우선한다.
• Domain=도메인명 : 쿠키가 전송될 도메인을 특정할 수 있다. 기본값은 현재 도메인이다.
• Path=URL : 쿠키가 전송될 URL을 특정할 수 있다. 기본값은 '/'이고 이 경우 모든 URL에서 쿠키를 전송할 수 있다.
• Secure : HTTPS일 경우에만 쿠키가 전송된다.
• HttpOnly : 설정 시 자바스크립트에서 쿠키에 접근할 수 없다. 쿠키 조작을 방지하기 위해 설정하는 것이 좋다.

 

 

로그인 전

 

로그인 후

 

원하는 대로 동작하기는 하지만 이 방식은 상당히 위험하다. 현재 Application 탭에서 보이는 것처럼 쿠키가 노출되어 있다. 또한, 쿠키가 조작될 위험도 있다. 따라서 이름 같은 민감한 개인정보를 쿠키에 넣어두는 것은 적절하지 못하다.

 

다음과 같이 코드를 변경하여 서버가 사용자 정보를 관리하도록 만들 수 있다.

 

 

 

로그인 전

 

로그인 후

 

이 방식이 세션이다. 서버에 사용자 정보를 저장하고 클라이언트와는 세션 아이디로만 소통한다. 세션 아이디는 꼭 쿠키를 사용해서 주고 받지 않아도 된다. 하지만 많은 엡 사이트가 쿠키를 사용한다. 쿠키를 사용하는 방법이 제일 간단하기 때문이다. 

물론 실제 배포용 서버에서는 세션을 위와 같이 변수에 저장하지 않는다. 서버가 멈추거나 재시작되면 메모리에 저장된 변수가 초기화되기 때문이다. 또한, 서버의 메모리가 부족하면 세션을 저장하지 못하는 문제도 생긴다. 그래서 보통은 데이터베이스에 넣어둔다.

서비스를 새로 만들 때마다 쿠키와 세션을 직접 구현할 수는 없다. 게다가 지금 코드로는 쿠키를 악용한 여러 가지 위협을 방어하지도 못한다. 위의 방식 역시 세션 아이디 값이 공개되어 있어 누출되면 다른 사람이 사용할 수 있다. 따라서 절대로 위의 코드를 실제 서비스에 사용해서는 안 된다.