쿠키와 세션을 사용하는 이유

(cookie는 클라이언트에 정보를 저장하는 기술, session은 서버에 정보를 저장하는 기술이다.)

  • http 프로토콜의 취약점을 해결해 주기위해서 사용한다 
  • HTTP 프로토콜 환경에서 서버는 클라이언트가 누구인지 확인해야한다 그 이유는 HTTP 프로토콜이 connectionless, stateless한 특성이 있기 때문이다. 
    • connectionless(비연결 지향) : 클라이언트가 서버로 부터 데이터를 요청한 후 데이터가 성공적으로 응답이 되면 연결을 바로 끊어 버리는 형식 
    • stateless(상태없음) : 통신이 끝나면 상태를 유지하지 않는 특성(상태 정보를 유지시키지 않음

http프로토콜의 이런 취약점을 해결 하기위해  쿠키세션을 사용하는 것이다!

  1. 사용자 정보를 기억하기 위해
  2. 클라이언트에서 서버로 인증하기 위한 절차 반복을 줄이기 위해

 


 

그렇다면 쿠키와 세션이란 무엇일까?

 

쿠키 

  • 쿠키는 클라이언트 로컬(local)에 저장되는 키와 값(key, value)이 들어있는 작은 데이터 파일이다.
  • 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
  • 만료 날짜/시간을 지정하지 않으면, '메모리에 있는 동안' 계속 유효하다고 판단하도록 세션 쿠키에 저장되고, 만료 날짜/시간을 지정하면 프로세스가 종료되더라도 특정 만료날짜/시간까지 유효하므로 지속 쿠키에 저장된다.지속 쿠키는 파일로 저장되므로 브라우저가 종료되어도 쿠키는 남아있게 된다.
  • 세션 쿠키는 브라우저 메모리에 저장되므로 브라우저가 종료되면 쿠키는 사라지게 된다.

 

 

쿠키의 구성요소

 

로그인을 한 후의 네이버 쿠키이다

  • 이름(name) : 각각의 쿠키를 구별하는 데 사용되는 이름
  • 값(values) : 쿠키의 이름과 관련된 값
  • 유효시간(expires) : 쿠키의 유지시간
  • 도메인(domain) : 쿠키를 전송할 도메인
  • 경로 (path): 쿠키를 전송할 요청 경로

 

쿠키의 동작 방식

  • 클라이언트가 페이지를 요청
  • 서버에서 쿠키를 생성
  • HTTP 헤더에 쿠키를 포함 시켜 응답
  • 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음
  • 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
  • 서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

쿠키 사용예시

  • 방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
  • 쇼핑몰의 장바구니 기능
  • 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크

 

 

 

세션

    • 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다(클라이언트에게 세션 ID발급해서 클라이언트는 쿠키로 저장 이 때문에 쿠키를 기반한 방식이라함)
    • 사용자의 대한 정보를 서버에 두기 때문에 쿠키 방식보다 보안에 더 장점이 있으나 사용자가 늘어날수록 서버 메모리의 큰 부담을 줘 성능 저하를 일으킬 수 있다.
      (추가 8.3) 사용자의 대한 정보를 메모리 > 하드디스크 > db(빨리 가져올 수 있는 순서)에 골라서 저장할 수 있다 
      메모리에 저장하는 경우 휘발성인 메모리의 특성상 서버가 꺼지면 사용자의 정보가 전부 사라진다

      그래서 레디스같은 메모리형 데이터베이스에 저장시키는데 이마저도 서버 에러가 발생하면 데이터가 전부 날라가는 문제점이있다!
  • 위의 이유로 서버를 여러대 두고 사용 세션방식을 이용 할 수 있으나 이 방법 또한 문제가 있다. 서버가 예를 들어 A,B,C가 있을시에 클라이언트가 처음 세션ID를 A라는 서버에서 발급받고 B라는 서버에 요청을 보내게 되면 B서버에서는 A서버에서 발급해준 세션ID를 알 지 못함으로 적절한 응답을 해줄 수 없다.

세션 동작 방식

  • 클라이언트가 서버에 접속 시 세션 ID를 발급 받는다.
  • 클라이언트는 세션 ID에 대해 쿠키를 사용해서 저장하고 가지고 있다.
  • 클라리언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 서버에 전달해서 사용함
  • 서버는 세션 ID를 전달 받아서 별다른 작업없이 세션 ID로 세션에 있는 클라언트 정보를 가져온다.
  • 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답함

 

쿠키와 세션의  차이점

  • 저장 위치
    • 쿠키는 클라이언트(브라우저)에 메모리 또는 파일에 저장하고, 세션은 서버 메모리에 저장된다.
  • 보안
    • 쿠키는 클라이언트 로컬(local)에 저장되기도 하고 특히 파일로 저장되는 경우 탈취, 변조될 위험이 있고, Request/Response에서 스나이핑 당할 위험이 있어 보안이 비교적 취약하다. 반대로 Session은 클라이언트 정보 자체는 서버에 저장되어 있으므로 비교적 안전하다.
  • 라이프 사이클
    • 쿠키는 앞서 설명한 지속 쿠키의 경우에 브라우저를 종료하더라도 저장되어 있을 수 있는 반면에 세션은 서버에서 만료시간/날짜를 정해서 지워버릴 수 있기도 하고 세션 쿠키에 세션 아이디를 정한 경우, 브라우저 종료시 세션아이디가 날아갈 수 있다.
  • 속도
    • 쿠키에 정보가 있기 때문에 쿠키에 정보가 있기 때문에 서버에 요청시 헤더를 바로 참조하면 되므로 속도에서 유리하지만, 세션은 제공받은 세션아이디(Key)를 이용해서 서버에서 다시 데이터를 참조해야하므로 속도가 비교적 느릴 수 있다.

 


 

 

세션/쿠키 인증 방식

(장점)

세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거치며 여기서 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠라고 생각하면 된다. 따라서 쿠키가 담긴 http요청이 도중에 노출이 되더라도 쿠키 자체(세션ID)는 유의미한 값을 가지고 있지 않아 보안이 쿠키만을 사용한 방식보단 훨씬 좋다. 또한 사용자 A,B가 있을때 고유의 ID값을 각각 받아 서버에서 사용자의 요청이 들어와도 일일이 회원 정보를 확인 하지 않고 어떤 회원인지를 바로 확인 할 수 있어 서버 자원에 접근이 용이하다.

추가 : 해커에게 세션 id를 털리거나 id변질시 해당 세션을 삭제 할 수 있음!!!!

 

 

(단점)

장점에서 쿠키를 탈취당하더라도 안전 할수 있다고 했지만 해커가 쿠키를 훔쳐 http요청을 보내면 서버의 세션 저장소에서는 사용자라고 판단하여 정보를 뿌려주게 된다.(세션 하이재킹 공격이라고 부름)

또한 앞서 정리한 성능 문제 및 서버를 여러대로 분산시킬 시에 발생하는 문제 등이있다.

 

 

 

 

이러한 쿠키/세션 방식을 해결하기 위한 방법으로 jwt가 등장했다..

(사실 여기까지의 글은 jwt글을 쓰기위한 빌드업 이였다....)

 

 

 

참고사이트 

출저 : https://tansfil.tistory.com/58?category=475681 

 

쉽게 알아보는 서버 인증 1편(세션/쿠키 , JWT)

앱 개발을 처음 배우게 됐을 때, 각종 화면을 디자인해보면서 프론트엔드 개발에 큰 흥미가 생겼습니다. 한때 프론트엔드 개발자를 꿈꾸기도 했었죠(현실은 ...) 그러나 서버와 통신을 처음 배

tansfil.tistory.com

https://interconnection.tistory.com/74

 

쿠키와 세션 개념

쿠키와 세션은 개발자 말고도 인터넷 사용자라면 누구나 많이 들어본 단어입니다. 하지만 개념에 대해서는 많은 사람들이 헷갈려 하기에 쉽고 간단하게 정리해보려고 합니다. 일

interconnection.tistory.com

https://jeong-pro.tistory.com/80

 

Web - 쿠키와 세션의 차이, 용도, 사용법(cookie,session)

웹에서 쿠키와 세션 쿠키와 세션을 사용하는 이유 → HTTP 프로토콜의 특징이자 약점을 보완하기 위해서 사용한다. HTTP 프로토콜의 특징 비연결지향(Connectionless) HTTP는 클라이언트가 요청(Request)

jeong-pro.tistory.com

 

'Web' 카테고리의 다른 글

Cookie/WebStorage (Local/Session Storage)차이  (0) 2021.08.03
Refresh/Access Token  (0) 2021.08.02
JWT  (0) 2021.08.02
CSRF  (0) 2021.08.02
XSS  (0) 2021.07.30

+ Recent posts