결국 중요한 데이터는 모두 서버에 저장해야 하며,
서버와 클라이언트 외에 추정 불가능한 무언가의 식별자가 있어야 한다.
전체적인 로직은 이렇다.
1. 클라이언트가 서버에 로그인아이디, 패스워드와 함께 로그인 요청을 한다.
2. 서버에서는 맞는 정보인지 찾아본다. 만약 맞다면, 세션 저장소에 예측할 수 없는 임의의 값(임의의값 + Hash나 UUID 등)을 세션id(일종의 key)로 넣고 value로 그 멤버의 정보를 저장한다.
3. 그 다음 쿠키로 이 세션 ID를 보낸다. 이러면 세션 아이디에서는 유저에 대한 정보를 전혀 예측할 수 없다. 또, 이 세션ID도 만약 무언가 외국 IP등 이상현상이 있으면 세션저장소에서 아예 지워버리거나, 또 대부분 이 세션을 짧게 (한 30분?) 유지시키고 그 후 파괴 시킨다.
저 세션ID는 예상 불가능 한 패턴이라 조금 바꿔서 다른 ID로 로그인 등이 불가능하다.
UUID의 임의 확률은 상상 이상이다.
근데 이렇게 해도, 솔직히 웹브라우저 쿠키 같은거 마음먹으면 충분히 탈취할 수 있을거다.
그럴 땐 어떡하나, 생각해 봤는데, 세션 저장소에 세션을 생성할 때 IP도 같이 저장하는거다.
그 후 다른 IP라면 튕겨내는 거다. 왜냐하면 처음 로그인 했단 것은 제대로 ID와 PASSWORD를 치고 들어오는 거니까,
쿠키를 통한 로그인 체크 말고 ID, PASSWORD를 통한 로그인 때만 세션을 생성해 주면 된다.
찾아보니까 Spring Secure라는 것도 있다.
'스프링 > 4. 스프링 MVC-2' 카테고리의 다른 글
50. 서버세션 적용 (0) | 2023.09.06 |
---|---|
49. 서버세션 구현 (0) | 2023.09.06 |
47. 쿠키의 보안문제 (0) | 2023.09.05 |
46. 쿠키를 이용한 로그인 구현. (0) | 2023.09.05 |
45. 로그인 구현 (0) | 2023.09.05 |