세션(Session) & 쿠키(Cookie)

JWT를 공부하기 전에 Web에서 클라이언트 식별과 관련하여 주로 사용되는 세션 및 쿠키에 대해 정리한 포스팅입니다.

 

Connectionless

HTTP 통신을 하기 위해서는 클라이언트와 서버가 연결되있어야 함.

커넥션은 유지 비용이 상당히 큼 → Stateless 방식 채택

 

---

Stateless

위의 Connectionless 특성을 이어받음

• HTTP 통신이 이전 요청의 상태를 기록하지 않음
• Stateful의 경우 이전 상태를 보존하며 이전 요청의 내용을 기억함.

위 두가지 특성으로 연결을 유지하지 않음으로써 클라이언트 식별문제가 발생

• WEB은 특정 클라이언트에게 Fit한 데이터(정보)를 서버에서 제공해야하기 때문에 클라이언트 식별이 강요됨.
  • 예를들어 장바구니, 로그인 등과 같이 특정 클라이언트에 대한 특정 연결을 유지해야할 필요가 생김.
• 이러한 식별 문제를 해결하기 위한 3가지 방식이 존재
  • 세션
  • 쿠키
  • 토큰

 

---

쿠키(Cookie)

Key-Value 형식의 키값쌍의 데이터

이러한 쿠키 데이터는 서버가 관리하는 것이 아닌 브라우저 단에서 관리 (ex : Chrome)

Feature

1. 이름, 값, 만료일(저장기간), 경로 정보로 구성되어 있음.
2. 클라이언트에 총 300개의 쿠키를 저장할 수 있음.
3. 하나의 도메인 당 20개의 쿠키를 가질 수 있음.
4. 하나의 쿠키는 4KB(=4096Byte)까지 저장 가능함.

쿠키의 종류는 2가지로 다음과 같음.

• 세션 쿠키
  • 만료일을 설정하지 않았기 때문에 브라우저를 종료하면 파기.
  • 사용자가 특정 사이트를 탐색할 때 선호 사항, 임시 설정 등을 저장하는 쿠키
    • 최근 본 상품
    • 최근 검색어
• 지속 쿠키
  • 디스크에 저장되어서 만료일까지는 브라우저를 끄거나 재부팅해도 남아있음.
  • 다음 방문에도 유지되는 설정 정보나 로그인 정보등을 저장하는 쿠키
    • 일주일 간 팝업 보지 않기
    • 로그인 유지

둘의 주요 차이점은 세션 쿠키의 경우 만료일을 지정하지 않았을 때이며, 지속 쿠키의 경우 만료일을 지정한 경우.

브라우저는 현재 세션이 끝나는 지점을 정의하며, 특정 브라우저에서는 재시작할 때 세션을 복원하여 무기한 존재할 수 있도록 하는 경우도 있음.

---

Operation

1. 클라이언트가 특정 리소스를 요청.

2. 서버는 쿠키를 생성

3. 생성한 쿠키에 정보를 담아 클라이언트에게 전송

4. 받은 쿠키는 클라이언트가 가지고 있다가(로컬 pc에 저장) 다시 서버에 요청할 때 요청과 함께 쿠키를 전송

5. 재방문 시 브라우저에 해당 쿠키가 있는 경우, 함께 재전송

Example

• 아이디 및 비밀번호 저장 기능
• 오늘 이 창을 다시 보지 않기 팝업창
• 비회원 장바구니 시스템

Spring Boot에서 쿠키를 다루는 간단한 예시 코드입니다.

@RestController
public class CookieController {

    @GetMapping("/visit")
    public int countVisit(@CookieValue(value = "visitCount", defaultValue = "0") int visitCount, HttpServletResponse response) {
        visitCount++;
        System.out.println(visitCount);
        Cookie cookie = new Cookie("visitCount", Integer.toString(visitCount));
        cookie.setMaxAge(24 * 60 * 60);  // 쿠키 유효 기간을 하루로 설정
        response.addCookie(cookie);
        return visitCount;
    }
}

Limited

1. 쿠키의 용량 제한.

2. 요청마다 헤더에 쿠키가 포함되기 때문에 보안의 문제가 발생할 수 있음.

      -> 로컬에 저장되기 때문에 변질되거나 스니핑 우려가 있음.

3. 브라우저마다 저장되는 쿠키가 다르기 때문에 브라우저끼리 공유가 불가능.

스니핑 공격이란 ?

도청의 기법으로, 네트워크 상에서 본인이 아닌 제 3자들의 패킷 교환을 엿듣는 공격을 의미함.

전송되는 쿠키값을 암호화하지 않고 전송하는 경우, 네트워크 스니핑을 통해 쿠키값이 탈취될 수 있음.

---

세션(Session)

일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술.

Feature

1. 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장.

2. 웹 서버의 저장되는 쿠키(=세션 쿠키)

3. 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋음.

4. 저장 데이터에 제한이 없다. (서버 용량이 허용하는 선에서)

5. 각 클라이언트에 고유 Session ID를 부여.

      -> Session ID로 클라이언트를 식별.

Operation

1. 클라이언트가 서버로 Request

2. 서버는 접근한 클라이언트의 Request-Header 필드의 Cookie를 확인

3. Session-id를 보냈는지 확인.

4. Session-id가 존재하지 않는다면 서버는 Session-id를 생성해 클라이언트에게 Response

5. 클라이언트는 서버로부터 받은 Session-id를 쿠키에 저장.

6. 클라이언트는 동일한 서버에 요청 시 이 쿠키의 Session-id값을 같이 전달.

Example

화면을 이동해도 로그인이 풀리지 않고 유지

 

Spring Boot에서 세션을 다루는 간단한 예시 코드입니다.

@RestController
public class SessionController {
    
    @GetMapping("/test")
    public Integer test(HttpSession httpSession, Model model) {

        Integer visitCount = (Integer) httpSession.getAttribute("visitCount");
        if (visitCount == null) {
            visitCount = 0;
        }
        visitCount++;
        System.out.println(visitCount);
        httpSession.setAttribute("visitCount", visitCount);
        model.addAttribute("visitCount", visitCount); //view에서도 사용할 수 있도록
        return visitCount;
    }
}

Limited

1. 서버의 메모리 공간을 사용하기 때문에 부하 증가.

2. 쿠키 탈취로 인한 정보 유출 우려. (브라우저에 저장하는 SessionId를 담은 쿠키를 말함)

3. 다중 서버 환경에서 개별적인 Session 관리를 할 경우 식별하지 못하는 경우가 발생.

 

---

Session과 Cookie의 라이프 사이클

세션과 쿠키의 중요한 차이점으로 라이프 사이클이 있음

 

Session : 브라우저가 종료되면 만료기간에 상관없이 삭제됨.

Cookie : 파일로 저장되기 때문에(Disk) 브라우저를 종료해도 정보가 유지될 수 있음.