[Security]Cookie/ Session/ JWT

Cookie/ Session/ JWT

 요약: HTTP의 비연결성(connectionless)와 비상태성(stateless) 특징 때문이다. 지속적인 연결을 필요

HTTP 포로토콜의 특징이자 약점을 보완하기 위해서 사용된다.

 

1. Connnectionless 프로토콜(비연결지향)

클라이언트가 서버에 요청(Request)을 했을 때,

그 요청에 맞는 응답(Response)을 보낸 후 연결을 끊는 처리방식이다.

- HTTP 1.1버전에서 연결을 유지하고, 재활용 하는 기능이 Default로 추가되었다. (keep-alive 값으로 변경 가능)

 

2.Stateless 프로토콜(상태정보 유지 안함)

클라이언트의 상태 정보를 가지지 않는 서버 처리 방식이다. 

클라이언트와 처번째 통신에서 데이터를 주고 받았다 해도,

두번째 통신에서 이전 데이터를 유지하지 않는다.

But, 실제로는 데이터 유지가 필요한 경우가 많다.

 

정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 다시 하거나, 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없거나 하는 등의 일이 발생할 수 있다.

-> 따라서, Stateless의 경우 대처하기 위해서 쿠기와 세션을 사용한다.

쿠키와 세션의 차이점은 크게 상태 정보의 저장 위치이다.

쿠키는 '클라이언트(=로컬 PC)'에 저장하고, 세션은 '서버'에 저장한다.

 

쿠키 인증 방식은 보안상 취약점이 있어. 따라서 보통 인증/인가 방식을 고민한다면 세션 방식을 사용할지, JWT 토큰 방식을 사용할지 고민하게 됩니다.

Cookie

Cookie -클라이언트가 인정 정보 관리(stateless)

장점: 쿠키에 정보가 있기 때문에 서버에 요청시 속도가 빠름

단점: 로컬에 저장되기 때문에  클라이언트(사용자)가 쉽게 쿠기에 담긴 인증 정보를 위조할 수 있고, 스니핑 당할 우려가 있어 보안에 취약합니다.  쿠키의 데이터 크기가 제한적이다. 4KB까지 저장

 

질문! 쿠키가 HTTP어느 파트에 있어요?

헤더(Header)

쿠키는 name-value 형식

 

쿠키를 주고 받을 때 HTTP 요청과 응답에 어떤 헤더 데이터가 오가는가? 쿠키 값을 어떻게 인코딩하나?

서버가 클라이언트에 여러 개의 쿠키를 저장하도록 지시할 때는 HTTP 응답 헤더에 다음과 같은 정보가 포함됩니다.

   - 프로토콜 종류, status Code, Content-Type, Set-Cookie

Set-Cookie 헤더를 사용하면 쿠키에 다양한 속성을 추가하여 설정할 수 있습니다.

 

쿠키 값의 인코딩

쿠키 값은 콤마, 세미콜론, 공백 문자를 제외한 나머지 출력 가능한 아스키 문자를 사용하기 때문에,

값으로 사용 가능한 문자가 한정되므로 쿠키 값을 생성할 때는 알맞은 방식으로 인코딩이 필요하다.

   - 쿠키 값을 자바에서는 java.net 패키지의 URLEnCoder 클래스를 통해 인코딩할 수 있다.

 

Seesion

Seesion- 서버가 인증 정보 관리(stateful)

장점: 서버에서 인증 정보를 관리하기 때문에 보안상 안전

단점: 사용자가 동시에 sessionId로 인증 요청을 많이 보내게 되면 서버 메모리가 부족해지고, 서버를 껐다 켰을 때 Session정보가 휘발

 

질문! Session에서 Httpsession를 사용합니다.

httpSession.getAttritube(“user”)

이렇게 사용자 A가 접속해도 user를 Key값으로 값을 가져오고,

사용자 B가 접속해도 user를 Key값으로 가져온다. 

같은 Key값을 쓰는데 어떻게 이들을 구별해서 가져올 수 있는걸까? 세션ID

 

• 일반 HTTP 요청에는 사용자 정보가 없으므로, 서버는 Session Tracking을 통해 요청자를 구분합니다.
• 가장 일반적인 방법은 쿠키를 사용하는 것:
  1. 서버가 세션 생성 시 세션ID(JSESSIONID)를 쿠키로 클라이언트에 전달
  2. 클라이언트는 이후 요청마다 이 쿠키를 전송
  3. 서버는 쿠키의 세션ID로 사용자별 세션 객체를 구분
• 따라서 같은 Key를 써도 세션ID가 달라 사용자별 데이터를 구분할 수 있습니다.

 

JWT

JWT – 클라이언트가 인증 정보 관리(stateless)

JWT(JSON Web Token)  HTTP 헤더에 담아서 서버로 보내는 방식입니다. 클라이언트가 인증 정보를 관리하기 떄문에 쿠키 인증 방식과 Flow가 비슷합니다. 다른 점은 쿠키가 아닌 JWT 토큰을 매개체로 인증한다는 것과 서버에서 '토큰 검증'이 이루어진다는 점입니다

장점: JWT는 인증에 필요한 모든 정보를 담고 있기 때문에 인증을 위한 별도의 저장소가 없어도 된다. Header 와 Payload를 가지고 Signature 를 생성하므로 데이터 위변조를 막을 수 있다, 토큰을 기반으로 oauth 등의 다른 시스템에 접근 및 공유가 가능하다.

단점: 토큰 길이가 길어, 인증 요청이 많아질수록 네트워크 부화가 증가, Payload 자체는 암호화되지 않기 때문에 중요한 정보를 담을 수 없다.

 

1) header : 해시 암호화 알고리즘과 토큰의 타입으로 구성

• 첫 번째는 HMAC, SHA256 또는 RSA와 같은 서명 생성에 사용된 해시 알고리즘
• 두 번째는 토큰의 유형 (JWT)

2) payload : 내용, 즉 토큰에 담을 클레임(claim) 정보를 포함

• Payload 에 담는 정보의 한 ‘조각’ 을 클레임이라고 부르며, name / value 의 한 쌍으로 이뤄짐
• 토큰에는 여러개의 클레임 들을 넣을 수 있음
• 클레임의 정보는 등록된 (registered) 클레임, 공개 (public) 클레임, 비공개 (private) 클레임으로 세 종류가 있음

3) signature : 서명

• Header, Payload, Secret Key를 합쳐 암호화한 결과값

JWT 단점 보완 전략

- 짧은 만료 기한 설정

토큰이 탈취되는 경우를 최소화하기 위해 사용한다. 하지만 이 경우 사용자가 자주 로그인해야 하는 불편함도 수반이 된다.

- Refresh Token

클라이언트가 로그인 요청을 보내면 서버는 AccessToken 보다 더 긴 만료 기간을 가진 Refresh Token을 발급하는 전략이다.

클라이언트는 Access Token이 만료되었을 때 Refresh Token을 사용하여 Access Token 재발급 요청을 한다. 서버는 DB에 저장된 Refresh Token과 비교하여 유효한 경우 새로운 Access Token을 발급해준다.

 

Access Token은 TTL을 짧게 설정해 자연 만료로 해결

Refresh Token은 블랙리스트로 관리해 성능 저하 방지

- 유효하지 않다고 판단된 JWT 토큰을 별도의 저장소 (DB, Redis 등)에 저장해 놓고, 이 토큰이 사용되는 요청을 차단하는 방식입니다.