[1주차 TIL] KnockOn Bootcamp, Cookie & Session

쿠키와 세션

쿠키(Cookie)

쿠키는 서버에서 클라이언트의 컴퓨터에 저장하는 작은 데이터 파일이다.

HTTP에서는 클라이언트의 상태정보를 쿠키 형태로 저장하여 필요할 때 참조하거나 재사용한다.

 

[쿠키의 특징]

• key-value로 구성되어 있는 데이터 파일이다.
• 구성 요소- 쿠키 이름, 쿠키 값, 유효시간, 도메인, 경로, 보안연결여부, HttpOnly 여부로 구성
• 클라이언트는 300개까지 쿠키 저장 가능, 도메인 당 20개의 쿠키를 가진다.
• 하나의 쿠키는 최대 4KB까지 저장

[쿠키의 사용 예시]

• 사이트 로그인 시 "아이디 비밀번호를 저장하시겠습니까?"
• 쇼핑몰 장바구니, 자동 로그인, 이 창을 다시 보지 않음 등 있다.

[쿠키의 종류]

• Session Cookie(임시 쿠키) - 만료기간 설저앟고 메모리에만 저장, 브라우저 종료시 쿠키 삭제
• Persistent Cookie - 장기간 유지되는 쿠키
• Secure Cookie - HTTPS에서만 사용, 쿠키 정보가 암호화되어 전송
• Third-Party Cookie - 방문한 도메인과 다른 도메인의 쿠키, 주로 광고, 배너 등 관리할 떄 유입 경로 추적용

[쿠키 동작 방식]

1.  클라이언트가 웹사이트 들어가 HTTP 요청
2. 서버에서 쿠키 생성하여 HTTP 헤더에 쿠키 포함하여 응답
3. 클라이언트는 쿠키 만료 기간까지 보관
4. 클라이언트가 다시 요청 시 HTTP 헤더에 쿠키와 함꼐 보냄
5. 서버에서 쿠키를 읽어 이전 상태 정보 변경할 시 업데이트하여 변경된 쿠키 HTTP 헤더에 쿠키 포함하여 응답

[쿠키의 단점]

쿠키는 클라이언트가 따로 보관하며, 클라이언트가 직접 수정할 수 있다.

-> 쿠키 값이 변조될 위험이 항상 존재한다.

 

세션 (Session)

세션은 쿠키를 기반하고 있고 서버에서 사용자 정보 파일을 저장한다.

세션은 클라이언트(브라우저)가 종료되기 전까지 클라이언트 요청을 유지하게 해준다.

 

[세션의 특징]

• 웹 서버에 상태를 유지하기 위한 정보 저장
• 웹 서버에 Session Cookie로 저장되고, 저장 위치는 서버의 메모리이다.
• 저장 데이터에 제한이 없다
• 각 클라이언트에 고유 세션 ID 부여, 각 클라이언트의 요구에 맞는 서비스 제공
• 브라우저 종료, 세션에서 삭제 시 Session ID 삭제 -> 보안상 이점

[세션 작동 방식]

1. 클라이언트 서버에 로그인 요청
2. 서버는 클라이언트 로그인 요청 확인, 클라이언트 고유 Session ID 생성하여 저장
3. 서버 응답할 떄 응답 헤더에 Session ID 쿠키 추가하여 응답
4. 클라이언트는 이후 서버에 요청할 떄 전달받은 Session ID를 쿠키에 자동으로 요청 헤더에 추가하여 요청
5. 서버에서는 요청 헤더의 Session ID 값을 세션 저장소에서 확인 후 요청 처리하고 응답

[세션의 단점]

세션의 내용은 서버에 저장되어 사용자가 늘려나면 서버에 부하

-> 동접자 수가 많으면 서버에 과부하로 성능 저하

세션에 대한 정보는 쿠키에 비해 속도가 느림

 

JWT(Json Web Token)

JWT은 토큰 인증 방식이며, JSON 객체를 사용하여 정보를 전달한다.

토큰은 사용자의 권한 정보, 서비스 사용 정보가 들어있다. 이 토큰은 클라이언트가 저장한다.

JSON

데이터를 구조화된 방식으로 표현하는데 사용되는 데이터 교환 방식

JSON 객체

JavaScript의 객체 표기법을 기반으로 하여 인간이 읽기 쉽게 설계되어 있는 것

 

[JWT 특징]

• 서버의 확장성이 높아 대량의 트랙픽을 대처 가능
• 특정 DB/ 서버에 대한 의존 없이 인증 가능
• Access Token 유효 기간을 짧게 하여 쿠키보다 보안성이 좋음
• Refresh Token은 네트워크 통신을 통해 서버로 보내서 정보 탈취 위험이 적음
• HTTP 특징인 stateless(무상태) 방식 이용

[JWT 단점]

• 많은 양의 데이터가 반복적으로 전송되어 네트워크 성능 저하됨
• 잠깐의 헤더와 페이로드 데이터 노출로 인한 보안 문제 있음

[JWT 동작 방식]

1. 사용자가 로그인 하면 서버에세 계정 정보 검증 후 Access Token과 Refresh Token 발급
2. 사용자는 Access Token을 저장 후 서버 요청할 때 HTTP 헤더에 Access Token 포함하여 전달
3. 서버는 해당 토큰의 권한, 유효, 인증, 정보를 보낸 사람이 바뀌지 않앗는지, 정보 변조에 대해 확인한 후 진행
4. 만약 Access Token이 만료되면 Refresh Token을 통해 Access Token 재발급

[JSON 구조]

JSON 구조는 크게 Header, Payload, Signature로 구성되다.

1. Header

 

• 토큰 유형(typ), 서명 암호화 알고리즘(alg)의 정보가 있음
• Base64로 인코딩되어 있다.

2. Payload

• 인증 제목(sub), iss(토큰 발급자), iat(토큰 발급시간), exp(토큰 만료시간) 등 데이터, 토큰에 대한 정보가 들어있다.
• 사용자, 토큰 같은 데이터 정보를 claim이라고 부른다.
• Base64로 인코딩되어 있다.

3. Signature

• 토큰을 인코딩하거나, 유효성(헤더, 페이로드 변조, 토큰 만료 등)을 검증할 때 사용하는 암호화 코드이다.
• 헤더 + 페이로드가 base64로 인코딩된 것을 헤더에 명시된 암호화 알고리즘을 통해 암호화한다.
• 암호화된 signature은 서버에서 비밀 키를 이용하여 확인할 수 있다.

 

브라우저 저장소

웹 브라우저가 제공하는 클라이언트에게 데이터를 저장하는 공간을 줌 (쿠키와 비슷한 개념)

HTML5부터 제공하는 기능이며 주로 구조화된 스크립트(JavaScript) 객체정보를 저장한다.

브라우저 저장소는 대표적으로 로컬 스토리지, 세션 스토리지가 있다.

 

로컬 스토리지(LocalStorage)

• 브라우저 종료해도 데이터 영구적 보관
• 도메인만 같으면 모든 브라우저 간에 데이터 공유

세션 스토리지(Session Storage) 

• 세션 스토리지에 저장된 데이터는 브라우저 연결과 종료까지만 저장함, 브라우저 종료시 삭제됨
• 도메인만 같더라도 브라우저 다르면 데이터 공유 x

 

실습

1. 네이버 접속 시 사용되는 쿠키들 확인해보기

개발자 도구에 어플리케이션 들어가 확인한 쿠키들이다.

 

Edit value을 클릭하여 이 값을 다 0으로 만들어보겠다.

 

2. 위에서 얻은 쿠키를 변조한 후 결과 분석

모든 쿠키의 value 값을 0으로 넣어봤다. 

 

이와 같이 변조된 것을 확인되는데 여기에서 PM_CK_loc 쿠키는 새로고침하니 다시 value 값이 넣어진다.

PM_CK_loc을 찾아보니 우리가 네이버 접속할 때 응답받는 쿠키의 값이다.