개요
쿠키와 세션은 많이 사용되고 있지만 헷갈리기 쉬운 개념이다.
오늘은 쿠키와 세션의 개념을 정리하고 차이점을 알아보려고 한다.
쿠키와 세션은 왜 사용할까?
기본적으로 HTTP 프로토콜 환경은 "connextionless(비연결성),stateless(무상태성)"한 특성을 갖고있다.
때문에 서버는 다수의 클라이언트와 연결을 유지하기 위해 불필요한 자원 낭비를 지속하는 상황을 방지할 수 있는 것이다. 하지만 이는 곧 서버가 클라이언트를 식별하지 못한다는 단점을 지니게 된다는 말이기도 하다.
예를 들어 로그인을 하였지만 서버는 이를 기억하지 못하므로 다음 요청 시 다시 로그인을 해야하는 문제가 발생한다.
우리는 로그인 이후, 장시간 사용하지 않거나, 로그아웃하지 않는 한 로그인이 유지되는 HTTP의 비연결성 및 무상태성을 보완한 Stateful한 환경을 위해 Cookie 와 Session 을 사용한다.
Cookie
클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
사용저 인증이 유효한 시간을 명시할 수 있고, 유효시간동안 브라우저가 종료되어도 유지된다.
쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조.
클라이언트에 300가지 쿠키 저장 가능하며, 하나의 도메인당 20개의 값만 가질 수 있고, 개당 4KB까지 가능
Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 시 Request Header를 넣어서 자동으로 서버에 전송
두 요청이 동일한 브라우저에 들어왔는지 아닌지 판단할 때 주로 사용, 이를 사용하면 사용자의 로그인 상태를 유지할 수 있다. 이를 통해 stateless 한 HTTP 프로토콜에서 브라우저의 상태를 기억할 수 있도록 한다.
쿠키의 사용 목적
세션 관리 - Session Management
-서버에 저장해야 할 로그인, 장바구니, 게임 스코어, 접속 시간 등의 개인정보 관리
개인화 - Personaliztion
-각 사용자에게 적절한 페이지를 보여줌 (사용자 선호, 테마 등의 세팅)
트래킹 - Tracking
-사용자의 행동과 분석하고 기록하는 용도
쿠키의 구성 요소
이름 : 각각의 쿠키를 구별하는데 사용되는 이름
값 : 쿠키의 이름과 관련된 값
유효시간 : 쿠키의 유지시간
도메인 : 쿠키를 전송할 도메인
경로 : 쿠키를 전송할 요청 경로
쿠키의 동작 순서
클라이언트가 페이지 요청
서버에서 쿠키 생성
HTTP 헤더에 쿠키를 포함시켜 응답
브라우저가 종료되어도 만료시간이 있다면 클라이언트에서 보관
같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답
쿠키의 사용 예
- 방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
- 쇼핑몰의 장바구니 기능
- 자동로그인, 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크, 쇼핑몰의 장바구니
쿠키는 어떻게 만들까?
Set-Cookie, Cookie Header
-브라우저마다 저장되는 쿠키는 다르다. ex) 크롬에 남긴 쿠키를 엣지에서 사용 불가
→ 브라우저가 다르다면 서버는 다른 사용자로 인식한다.
클라이언트 요청 시, 서버는 응답할 때 쿠키에 저장하고자 하는 정보를 헤더에 전달
Set-Cookie: <cookie-name>=<cookie-value>클라이언트는 서버로 전송하는 모든 요청에, 현재 브라우저에 저장된 모든 쿠키를 Header에 Cookie로 전달
Cookie: <cookie-name>=<cookie-value>웹 브라우저의 개발자 도구에서 Application 탭에서 저장된 Cookies 를 확인 가능하다.
쿠키의 LifeTime
Session Cookie & Permanent Cookie
쿠키의 라이프타임은 두 가지 방법으로 정의될 수 있다.
Session 쿠키란 웹 브라우저가 종료될 때 제거된다. 즉 세션이 끝날 때 삭제되는 쿠키를 말한다.
(예제에서 살펴본 쿠키)
브라우저 종료 시에도 쿠키를 유지시키고 싶다면 , Permanent 쿠기를 이용하면 된다. 쿠키를 생성할 때 Expires 또는 Max-Age 옵션을 추가하면 된다.
-Expires : 쿠키가 만료될 날짜 지정
-Max-Age : 현재 시간을 기준으로 얼마동안 쿠키를 유지시킬 것인지 지정
Set-Cookie: cookie-name=cookie-value; Expires=Wed, 21 Apr 2024 10:00:00 GMTSecure & HttpOnly & Path & Domain 옵션
-Secure : HTTPS 프로토콜 상에서 암호화된 요청일 경우에만 전송
-HttpOnly : Cross-site 스크립팅 공격을 방지 . javascript의 document.cookie Api 에 접근 할 수 없도록 함
-Domain,Path : 쿠키의 스코프를 정의
Set-Cookie: cookie-name=cookie-value; secure; httpOnly;Session
클라이언트의 웹 브라우저에 쿠키를 저장해놓고, 매 요청마다 헤더에 쿠키를 넣어 전달하는 방식으로 인증을 구현할 경우, 쿠키가 유출되거나 조작될 수 있는 등 보안상 결함이 존재한다. 개인 소유가 아닌 공용 컴퓨터에서 사용할 경우, 누구나 그 사용자의 비밀번호를 확인 할 수 있게되며 HTTP 로 개인 정보를 주고 받는 것은 매우 위험하다.
비밀번호를 비롯한 인증 정보를 쿠키가 아닌 , 서버 측에서 저장하고 관리하는 방식
HTTP/1.1 200
Set-Cookie: JESSIONID=<JESSIONID_value>서버는 클라이언트에 로그인 요청에 대한 응답을 작성할 때, 인증 정보는 서버에 저장하고 사용자의 식별자인 JSESIONID(session_id) 를 쿠키에 담아 전송. 이후 클라이언트는 요청을 보낼 때마다 JSESSIONID 쿠키를 함께 보내고, 서버는 이 ID 의 유효성을 판별하고 크라이언트를 식별한다.
웹 브라우제 쿠키를 저장하여 HTTP로 전송하는 방식 대신, 서버에 사용자의 인증 정보를 저장하며 session_id를 쿠키에 담아 전송하는 Session 방식이 보안상 이점을 갖는다.
세션의 동작 순서
클라이언트가 서버에 처음으로 Request 를 보냄 (session_id가 존재하지 않는 상태)
서버에는 session id 쿠키 값이 없는 것을 확인하고 새로 발급하여 응답
클라이언트는 전달 받은 session id 값을 매 요청마다 헤더 쿠키에 넣어 저장
서버는 session id 를 통해 사용자를 식별
클라이언트가 로그인 요청 시, 서버는 session 을 로그인 사용자 정보로 갱신 후 새로운 session id 를 발급 하여 응답
이후 클라이언트는 로그인 사용자의 session id 쿠키를 요청과 함게 전달
클라이언트 종료 시, session id 제거 후 서버에서도 session 제거
session의 특징
session id는 브라우저 단위의 저장하고, 브라우저 종료 시 소멸
-클라이언트에게 고유한 session id 발급
-session id 로 클라이언트를 구분 하여 서비스 제공
-보안면에서 cookie 보다 우수
-사용자가 증가할 수록 서버 메모리를 많이 사용
로그인한 사용자에 대해서만 세션을 생성하는 것이 아니라,request 요청 시 세션 저장(로그인 후 갱신) 따라서 로그아웃 시 새로운 사용자로 인식하여 세션 생성
사용자의 로그인 상태, 닉네임 등 사용자가 요청 할 때마다 필요한 정보를 세션에 담아두면 사용자 DB에 접근할 필요가 없어 효율적
장점과 보안적 결함
장점
-각 사용자마다 고유한 session id 가 발급되므로, 요청이 들어올 때마다 회원 정보를 DB에 접근하여 확인 할 필요가 없다.
단점
-쿠키를 포함한 요청이 외부에 노출 되더라도, 세션 ID 자체는 유의미한 개인정보를 담고 있지 않으므로 쿠키 방식보다 안전하다 그러나 누군가 session id 를 탈취하여 클라이언트로 위장 하여 로그인 할 수 있다는 한계가 존재.
-서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버의 부하가 심해진다.
설정
https 를 이용한 통신이 좋으며, cookie 와 마찬가지로 session의 secure 옵션을 true 로 주어 https 에서만 세션 정보를 주고 받을 수 있으며, httpOnly 옵션을 주어 js를 통한 세션 쿠기 사용을 막을 수 있다.
캐시
웹 페이지 요소를 저장하기 위한 임시 저장소. 특히 필요할 것 같은 요소들을 저장(그림 파일 , 문서 파일 등) 웹 페이지가 빠르게 렌더링할 수 있도록 도와주며 사용자가 수동으로 삭제해주어야 한다.
쿠키와 세션의 차이
- 세션도 결국 쿠키를 사용하므로 동작과 역할이 비슷하다.
- 가장 큰 차이점은 사용자의 정보가 저장되는 위치이다. 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용합니다.
- 보안 면에서 세션이 더 우수하며, 요청 속도는 쿠키가 세션보다 더 빠르다. 그 이유는 세션은 서버의 처리가 필요하기 때문입니다.
- 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 sessionid 만 저장하고 그것으로 구분해서 서버에서 처리하기 때문에 비교적 보안적 이점을 갖는다.
- 쿠키도 만료시간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 계속해서 정보가 남아 있을 수 있다. 또한 만료기간을 넉넉하게 잡아두면 쿠키삭제를 할 때 까지 유지될 수도 있다.
- 세션도 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제. 예를 들어, 크롬에서 다른 탭을 사용해도 세션을 공유. 다른 브라우저를 사용하게 되면 다른 세션을 사용할 수 있습니다.
- 속도, 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠르고 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 갖는다.
캐시는 이미지나 css, js 파일 등을 브라우저나 서버 앞단에 저장해놓고 사용한다 (CDN)
한번 캐시에 저장되면 브러우저를 참고하기 때문에 서버에서 변경이 되어도 사용자는 변경 되지 않게 보일 수 있는데 이러한 부분을 캐시 지우기나 header 에 만료 시간을 명시하는 방법 등을 이용할 수 있다
보통 쿠키와 세션의 차이를 물어볼 때 저장위치와 보안에 대해 이야기 하는데 이는 곧 라이프 사이을 이야기 하는 것이다.
보안적 이점은 가는 세션을 사용하면 안되나요?
세션은 서버의 자원을 사용하기 때문에 사용자가 많을 경우 서버의 메모리가 감당 하지 못할 수 있다. 때문에 속도가 느려지고 무거워질 수 있기 때문에 쿠키가 유리한 경우가 있다.
