Session

저번엔 브라우저에 데이터가 저장되는 Cookie에 대한 개념을 위주로 정리했다면, 이번에는 Session에 관해서, 특히 Session기반 인증에 관해서 정리해보려고 한다. 

 

Session이란?

 

스택오버플로우에 나온 정의..

"Session" is the term used to refer to a user's time browsing a web site. It's meant to represent the time between their first arrival at a page in the site until the time they stop using the site.

 

Session이란 용어는 유저가 웹사이트를 방문했을 때, 언급되는 용어이다. 유저가 웹사이트에 처음 방문해서 서비스 이용 후, 웹사이트 창을 닫을때까지의 시간, 즉 웹사이트를 이용하는 시간동안 서버로 보내는 요청들을 하나의 상태로 인식하고 그 상태를 일정하게 유지시키는 "기술"을 의미한다. 

유저 인증시, 유저의 정보를 브라우저에 담는 쿠키와 달리, 세션은 유저의 정보를 서버에 저장한다. 서버에 유저정보를 저장할 수 있기 때문에 유저정보를 탈취당할 가능성이 쿠키에 비해 확 줄어든다. 그 Session을 기반으로 한 인증절차를 그림으로 살펴보면 다음과 같다. 

 

출저: 코드스테이츠

1. 유저 Jane이 생활용품을 판매하는 웹사이트에 방문했다고 하자. Jane은 soap를 장바구니에 담기 버튼을 눌렀는데 로그인을 하라는 창이 뜬다.

 

2. Jane은 일단 로그인을 시도한다. 유저이름과 비밀번호를 입력하면 브라우저는 정보를 payload에 담아 서버에 요청을 한다.

 

3. 서버는 DB에서 해당 payload 정보와 일치하는 유저가 있는지 확인한다. 다행히 DB에 일치하는 정보가 있었고, DB에 soap를 담는다.

 

4. 그리고 서버는 메모리스토리지(특정, session store를 사용하지 않을 시 기본설정되는 storage)에서 sessionId를 생성해서 cookie에 담아 Jane(클라이언트)에게 보낸다. sessionId는 db에 저장한다. 

 

5. 쿠키안에 sessionId를 발급받은 Jane은 다른 물건을 장바구니에 담는 요청을 보낼때, cookie에 담긴 sessionId를 함께 보내면 서버는 요청과 같이 온 sessionId가 DB에 저장되어 있는지, 누구의 sessionId인지를 확인한 후, 일치하는 정보가 있다면 물건을 DB에 저장한다.  

 

위 방식은 유저정보를 브라우저 저장하지 않고 대신, 탈취되도 별 문제없는 암호화된 sessionID를 발급한다. 그래서 유저가 요청을 보낼때마다 sessionId를 함께보내, 서버가 sessionId만으로 방금 보낸 요청이 누구의 요청인지 확인할 수 있다. 

 

그리고 반드시 세션을 파괴하는 과정이 필요하다. 왜냐하면, 만약 sessionId가 담긴 쿠키를 해커가 탈취해서 요청을 보낸다면, 서버는 sessionId만으로 누가 보냈는지 확인하기 때문에, 해커가 요청을 보내도 sessionId가 db에 저장되어 있다면 알맞는 응답을 보내줄 것이다. 즉, 서버는 그 요청을 해커가 보냈는지, 실제 사용자가 보냈는지 확인할 수도 없고, 오직 요청들어온 sessionId만 db에 저장되어 있는지 확인하고 응답을 보내줄 것이다. 이런 취약점 때문에, 로그아웃을 하면 해당 유저의 세션을 파괴하고, 다시 로그인 했을 때, 새로운 sessionId를 발급해주는 것이 좋다. 

 

참고: stackoverflow.com/questions/3804209/what-are-sessions-how-do-they-work