세션과 쿠키

우리가 로그인을 한다고 생각해보자. 

 

서버는 우리가 누군지 모르지만

id와 비번을 입력하고 DB에서 데이터를 조회하는 순간

우리가 누구인지 알게될것이다.

 

하지만. 또다른 요청을 보내면 서버는 우리가 누군지 모른다. 그러므로 다시 조회를 해야한다.

이렇게 된다면 요청을 보낼때 계속 id와 비번을 보내야하고 

db는 그걸 계속 조회하는 상황이 발생할것이다.

 

이를 예방하기위해 Cookie라는 것이 있다.

쿠키는 사용자가 최초 로그인했을시 서버에서는 어 너로그인 했구나.

너한테 쿠키 하나 보낼게. 다음 요청부터는 로그인(아이디 비밀번호) 안해도 되고 내가 쿠키에다가 너를 구별하는 정보를 써놓았으니까 그 쿠키를 나한테 보내줘. 그러면 내가 알아서 식별할게 라고 한다.

이로서 쿠키는 포스트잇:데이터 쪼가리라고 할 수 있다. 그리고 데이터중에 사용자 정보를 담아서 누구인지 구별하는것이다.

 

그래서 다음 요청부터는 비밀번호를 입력하지 않고 쿠키를 보내서 요청하는것이다.

그러면 쿠키에 담긴 데이터를 가지고 서버는 id와 비번을 받지 않아도 누가 요청했는지 알수 있다.

 

하지만, 이 쿠키의 단점은 생성측은 서버지만 관리측이 클라이언트라는것이다.

클라이언트에서 데이터를 관리하니까 서버는 가벼워지는게 장점이다.

하지만 클라이언트에 가면 무엇이 문제일까? 바로 변조가 쉽게 가능한것이다.

그래서 쿠키에 담긴 정보를 내 정보가 아닌 다른 사람의 정보로 바꿔버린다면?

맞다. 서버는 지금 요청한게 내가 아니라 그 다른 사람이 요청한건줄 안다.

그래서 다른 사람의 정보가 털릴수도 있고 심지어 관리자 까지도..

 

그래서 그것을 막기 위해서 세션이라는것이 또 있다.

세션은 쿠키와 다르게 서버측에서 관리하는곳이다. 

사용자가 id를 입력하면 서버의 세션 컨테이너에 id가 저장된다.

이렇게 세션에 저장하면 데이터가 노출되지 않는 장점이 있다.

하지만 여전히 문제는 존재한다. 이게 누구 id인지 알 수 없다는것이다.

그래서 서버측은 클라이언트가 접속했을때

SessionID (서버측에서 알 수 있는 식별아이디)  를 생성해서 쿠키로 보낸다. 그러면 클라이언트가 요청했을때 SessionID를 보고 아 누구누구 세션 주소군! 여기 ID가 있으면~ 너 권한 있음. ID가 없으면 ~ 너 로그인해. 이런 느낌이다.

 

그렇다. 이 SessionID는 서버측에서 식별할수있는 고유 번호이자 키이다.

하지만 그것은 클라이언트에 존재한다. 

=SessionID를 털리면 내 개인정보가 털린다.

 

하지만 SessionID는 랜덤한 난수로 이루어져있어서 쉽게 털수는(추측할수는) 없다.

하지만 XSS 공격을 당하면 SessionID가 탈취될 수 있기 때문에 XSS 공격에 주의해야한다.

 

간단한 예시 그림이다.

정리하자면 쿠키는 클라이언트가 관리하고 세션은 서버가 관리한다.

인증 정보들을 모두 쿠키로 보내버리면 변조될 가능성이 높기때문에 

ID키 하나만 쿠키로 보내놓고 나머지는 모두 서버에서 저장하고 처리하는것이다.

ID키(Session ID)는  랜덤한 난수이므로 추측이 어려워서 보안성이 있지만

클라이언트에 저장되는것이라 다른 사람이 탈취하면 내 정보가 들어있는 세션이 탈취되는것이다.

그러므로 쿠키를 탈취할 수 있는 XSS 공격에 주의해야한다.