쿠키와 세션, 그리고 서블릿 HTTP 세션

 

 

# 쿠키의 2가지 종류

1. 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지

2. 세션 쿠키 : 만료 날짜를 생략하면 브라우저 종료시 까지만 유지 

 

 

 

 

# refreshToken은 httpOnly쿠키로 셋팅하고 accessToken은 json으로 응답을 리턴하는 코드

@PostMapping(value = "/api/v1/authenticate")
    public ResponseEntity<?> createAuthenticationToken(@RequestBody JwtRequest authenticationRequest, HttpServletResponse response) throws Exception{
        authenticate(authenticationRequest.getUsername(),authenticationRequest.getPassword());
        final UserDetails userDetails = userDetailService
                .loadUserByUsername(authenticationRequest.getUsername());
                
        final String token = jwtTokenUtil.generateToken(userDetails);
        
        ApiResponse apiResponse = new ApiResponse();
        apiResponse.setData(token);
        
        ResponseCookie responseCookie = ResponseCookie.from("refreshToken",refreshToken)
                .httpOnly(true)
                .secure(true)
                .path("/")
                .maxAge(60)
                .domain("yourdomain.net")
                .build();
                
        return ResponseEntity.ok()
                .header(HttpHeaders.SET_COOKIE, responseCookie.toString())
                .body(apiResponse);
       
    }

 

 

 

# 쿠키와 보안 문제

1. 쿠키의 값은 임의로 변경할 수 있다. 

    - 클라이언트가 쿠키를 강제로 변경하면 다른 사용자가 된다. 

2. 쿠키에 보관된 정보는 훔쳐갈 수 있다. 

    - 만약 쿠키에 개인정보나, 신용카드 정보가 있다면?

    - 이 정보가 웹 브라우저에도 보관되고, 네트워크 요청마다 계속 클라이언트에서 서버로 전달된다. 

    - 쿠키의 정보가 나의 로컬 PC에서 털릴 수도 있고, 네트워크 전송 구간에서 털릴 수도 있다. 

3. 해커가 쿠키를 한번 훔쳐가면 평생 사용할 수 있다.

    - 해커가 쿠키를 훔쳐가서 그 쿠키로 악의적인 요청을 계속 시도할 수 있다. 

 

 

* 대안 

1. 쿠키에 중요한 값을 노출하지 않고 , 사용자 별로 예측 불가능한 임의의 토큰(랜덤 값)을 노출하고, 서버에서 토큰과 사용자 id를 매칭해서 인식한다. 그리고 서버에서 토큰을 관리한다. 

2. 토큰은 해커가 임의의 값을 넣어도 찾을 수 없도록 예상 불가능 해야 한다.

3. 해커가 토큰을 털어가도 시간이 지나면 사용할 수 없도록 서버에서 해당 토큰의 만료시간을 짧게 (예: 30분) 유지한다. 또는 해킹이 의심되는 경우 서버에서 해당 토큰을 강제로 제거하면 된다.

 

 

---

---

# 세션

- 쿠키의 보안 문제를 해결하려면 결국 중요한 정보를 모두 서버에 저장해야 한다. 

- 그리고 클라이언트와 서버는 추정 불가능한 임의의 식별자 값으로 연결해야 한다.

 

- 이렇게 서버에 중요한 정보를 보관하고 연결을 유지하는 방법을 세션이라 한다. 

 

- 세션 ID를 생성하는데, 추정 불가능해야 한다.

- UUID는 추정이 불가능하다.

    - Cookie: mySessionId=zz0101xx-bab9-4b92-9b32-dadb280f4b61`

- 생성된 세션 ID와 세션에 보관할 값( `memberA` )을 서버의 세션 저장소에 보관한다.

 

- 클라이언트와 서버는 결국 쿠키로 연결이 되어야 한다.

    - 서버는 클라이언트에 mySessionId 라는 이름으로 세션ID만 쿠키에 담아서 전달한다.

    - 클라이언트는 쿠키 저장소에 mySessionId 쿠키를 보관한다.

 

 

* !!중요

- 여기서 중요한 포인트는 회원과 관련된 정보는 전혀 클라이언트에 전달하지 않는 다는 것이다.

- 오직 추정 불가능한 세션 ID만 쿠키를 통해 클라이언트에 전달한다. 

 

- 클라이언트는 요청 시 항상 mySessionId 쿠키를 전달한다. 

- 서버에서는 클라이언트가 전달한 mySessionId 쿠키 정보로 세션 저장소를 조회해서 로그인 시 보관한 세션 정보를 사용한다. 

 

 

** 정리 

- 세션을 사용해서 서버에서 중요한 정보를 관리하게 되었다. 덕분에 다음과 같은 보안 문제들을 해결할 수 있다. 

1. 쿠키 값을 변조 가능 → 예상 불가능한 복잡한 세션 ID를 사용한다. 

2. 쿠키에 보관하는 정보는 클라이언트 해킹시 털릴 가능성이 있다. → 세션 ID가 털려도 여기에는 중요한 정보가 없다. 

3. 쿠키 탈취 후 사용 → 해커가 토큰을 털어가도 시간이 지나면 사용할 수 없도록 서버에서 세션의 만료시간을 짧게 (예: 30분) 유지한다. 또는 해킹이 의심되는 경우 서버에서 해당 세션을 강제로 제거하면 된다. 

 

 

- 사실 세션은 뭔가 특별한 것이 아니라, 단지 쿠키를 사용하는데, 서버에서 데이터를 유지하는 방법일 뿐이다.

 

 

---

# 서블릿 HTTP 세션

- 서블릿은 세션을 위해 HttpSession 이라는 기능을 제공한다. 

- 서블릿을 통해 HttpSession을 생서앟면 다음과 같은 쿠키를 생성한다. 

Cookie: JSESSIONID=5B78E23B513F50164D6FDD8C97B0AD05

 

 

- 서블릿의 HttpSession이 제공하는 타임아웃 기능 덕분에 세션을 안전하고 편리하게 사용할 수 있다. 

- 실무에서 주의할 점은 최소한의 데이터만 보관해야 한다는 점이다. 

- 보관한 데이터 용량 * 사용자 수 로 세션의 메모리 사용량이 급격하게 늘어나서 장애로 이어질 수 있다. 

- 추가로 세션의 시간을 너무 길게 가져가면 메모리 사용이 계속 누적될 수 있으므로 적당한 시간을 선택하는 것이 필요하다.

- 기본이 30분이라는 것을 기준으로 고민하면 된다.