세션, 쿠키

답변으로 추가 질문하셔서 답변이 된 질문인 줄 알고 강사분이 그냥 넘어가셨나보네요.

우선 쿠키와 세션의 하는 일은 거의 비슷합니다. 가장 큰 차이는 쿠키는 클라이언트가 관리하고 세션은 서버에서 관리한다는 거예요.

그럼, 최대한 쉽게 설명을 드려볼께요!

HTTP의 특성 중 비연결성과 비상태성이 있는데 이는, 사용자의 요청에 따른 응답 후에 연결을 유지하지 않고 연결 해제 후에도 상태 정보를 저장하지 않습니다.

따라서, 클라이언트는 요청할 때마다 자신의 정보를 함께 제공해야해요. 대표적인 예시로 ID와 PW겠죠?

HTTP가 연결을 유지하지 않고 정보도 저장하지 않는 특성을 가지고 있으니까 사용자는 매 요청마다 ID와 PW를 통해서 로그인 인증을 해야하는 불편함이 생기죠.

그걸 해결하고자 하는게 쿠키라는 개념입니다.

쿠키라는 곳에 내 로그인 정보를 저장해놓고 사용자가 요청할 때 자동으로 함께 보내지면 사용자는 매번 정보를 적지 않아도 되겠죠?

하지만 내 로그인 정보를 적어놓은 쿠키라는 것이 남이 보거나 가져가면 내 정보가 유출되는 거잖아요?

그래서 세션이라는 개념이 나와요. 물론 세션도 쿠키 기반입니다.

사용자가 처음 로그인하면 서버는 세션ID라는 것을 만들고 세션ID와 사용자와 관련된 모든 정보를 DB에 저장합니다. 그리고 사용자에게 세션 ID를 알려주면, 사용자는 세션 ID를 쿠키에 저장하죠.

그리고 매번 요청을 보낼 때마다 세션 쿠키를 함께 보냅니다. 그럼 서버는 세션ID를 가지고 사용자를 구분하게 되는 것이죠. 어때요? 매번 로그인 정보가 담긴 쿠키를 보내는 것보단 안전하겠죠?

(이해는 여기까지만 하셔도 되요. 아래는 세션의 장/단점이랑 보안 관점에서의 부가적인 설명일 뿐이예요.)

그럼 또 의문이 들겠죠? 해커가 세션 ID를 가져가면 결국 ID, PW를 가져간 것과 뭐가 다른가?

네, 그래서 추가적인 보안이 필요해요. 그건 뒤에 설명드리고 일단 세션을 사용하면 장점은 아래와 같아요.

첫째로 로그인 정보가 직접적으로 노출되지 않습니다. 세션 ID는 쿠키와 마찬가지로 언젠가는 만료되요. 하지만 로그인 정보가 담긴 쿠키가 유출된다면 해커는 언제든지 다시 로그인할 수 있겠죠?

둘째로 쿠키는 서버 측에서 설정한 만료기간(시간~일)이 되어야 만료가 됩니다. 사용자가 브라우저를 닫더라도 쿠키는 유효한 상태라는거예요. 반면, 세션은 브라우저가 종료되면 세션도 만료가 됩니다.

셋째로 세션은 서버 측에서 관리하기 때문에 제어도 가능합니다. 그 말은, 특정 유저를 강제로 로그아웃 시킬 수 있다는 거예요. 예를 들면 카카오톡이나 인스타의 기능 중에 사용자가 로그인된 모든 기기를 확인하고 원하지 않는 기기는 원격 로그아웃 시킬 수 있는데 이건 서버 측에서 세션을 관리 중이기 때문에 가능한거예요. 또 넷플릭스처럼 몇 명이 로그인했는지 확인하고 제한할 수도 있어요.

그럼 무조건 세션을 써야하는가?라는 의문이 들 수 있어요. 세션을 쓰면 좋죠. 보안성이 좋으니까요. 다만 몇가지 단점을 말씀드리자면 일단 쿠키에 비해 느려요. 서버 측에서 세션 DB로 가서 확인하는 과정이 있기 때문에 쿠키에 비해서 느려질 수 밖에 없죠.

그리고 서버 측에서 관리되고 절차가 이루어지기 때문에 서버의 리소스(자원)에 부담이 되겠죠? 또 세션DB가 필요하기 때문에 사용자가 많아질 수록 DB가 커져야해요. 서버나 DB를 증설(혹은 업그레이드)하는 것도, 유지보수하는 것도 다 비용이죠.

그럼 쿠키는 무조건 안 좋은건가? 그건 또 아니예요. 위에서 말한대로 세션이 여러가지로 부담되기 때문에 사용자가 많지 않거나 프로젝트의 규모가 작다면, 쿠키의 취약한 부분을 자체적으로 혹은 자바스크립트를 이용한다던가 아니면 외부 서드파티를 통해서 등등 어떤 식으로든 보완할 수 있는 방법이 존재하긴 해요. 다만, 그런 우회적인 방법들은 한계가 있기 때문에 서비스가 커지면 세션으로 관리하는게 훨씬 좋죠.

마지막으로 결국 세션도 추가적인 보안이 필요하다고 했는데, 그거에 대해서 간단하게만 설명해드릴께요. 해커가 세션 ID를 훔친다고 해도 세션 ID가 유효할 때만 사용할 수 있으니, 사용자가 사용 중일 때만 해커도 사용할 수 있어요. 상당히 국한되어 있는거죠. 하지만 이 역시도 문제는 있는거죠?

그래서 서버 쪽에서도 세션 ID만을 가지고 인증을 하면 안 됩니다. IP 정보와 엮어서 확인한다던가 부가적인 요소나 절차가 필요해요. 이 역시도 여러 문제가 있지만 이미 글이 너무 길어져서 그만 써야겠네요 ㅎㅎ;;

개발할 때는 보안도 고려해야하는데 창과 방패의 대결이죠. 이렇게 개발했는데 이렇게 취약해서 그것을 보안하기 위해 이렇게 수정했는데 그게 우회되기도하고 때로는 그것으로 인해 다른 취약점이 발견되기도 하고.. 개발자는 또 그걸 대응해야하고.. 하나하나 설명하자니 멈출 때를 모르겠네요 ㅋㅋ.. 여하튼 이해하는데 도움이 되었길 바래요!

인프런 커뮤니티 질문&답변