쿠키, 세션, 캐시, 토큰

쿠키

 - 서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를

   응답 헤더의 set-cookie에 담는다.

 - 이후 클라이언트가 재용청할 때마다 저장된 쿠리를 요청 헤더의 cookie에 담아 보낸다.

 - 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별할 수 있다.

 - 보안에 취약, 용량제한, 브라우저간 공유 불가능 같은 단점이 있다.

 - 브라우저가 닫혀도 정보를 가지고 있는다

 

1) Session Cookie : 메모리에만 저장되며, 브라우저가 닫힐 때 삭제

2) Persistent Cookie : 기간 설정을 하고 브라우저가 닫혀도 삭제되지 않고 기간에만 반응한다.

3) Secure Cookie : HTTPS에 사용되는 암호화된 쿠키, 실질적 보안은 안된다.

4) Third Party Cookie : 다른 도메인에 요청이 필요할 때 생성되는 쿠키, 광고 목적으로

                                     사용되는 것이다.

 

장점

1) XSS로부터 안전 - 서버에서 쿠키의 httpOnly 옵션을 설정하면, Js에서 쿠키에 접근

    불가

2) 대부분의 브라우저가 지원

 

단점

1) 매우 작은 데이터 저장 용량(4kb) → 쿠키 스토리지가 대체할 수 있음

2) CSRF(사이트 간 요청 위조) 위협  - 공격자가 사용자의 요청을 가로챈 뒤

    사용자의 의지와 상관없이 보안적으로 위험한 행동을 하게끔 변조하여 부당 이익을

    취하는 행위

3) 문자열만 저장 가능

세션

- sission은 비밀번호와 같은 인증 정보를 쿠키에 저장하지 않고 대신에 사용자의 식별자인

  session id를 저장한다. 

- 세션 ID를 탈취할 수 있고 (IP같은 것으로 해결한다) 요청이 많아지면 서버에 부하가 심해진다.

- 브라우저를 닫으면 일반적으로 끊긴다.

캐시

- 캐시는 웹 페이지 요소를 저장하기 위한 임시 저장소이다.

- 주로 브라우저에서 빠르게 랜더링을 하도록 도와주는 역할을 하는데 정적인 파일 즉, js, html, css, image

  등을 가지고 있는 것이다.

 

토큰(Header, payload, signature)

 

JWT JSON 데이터

 

Header

 - 헤더는 jwt를 어떻게 검증하는가에 대한 내용을 담고 있다. alg는 서명시 사용하는 알고리즘이고

   kid는 서명시 사용하는 키(public/private)를 식별하는 값

 

Payload

 - JWT의 내용(토큰 생성자의 정보, 생성일시...)이나  클라이언트와 서버 간 주고받기로 한 데이터들로 구성된다.

 

Signature

 - 점(.)을 구분자로 해서 헤더와 페이로드를 합친 문자열을 서명한 값이다. 헤더의 alg에 정의된 알고리즘과 비밀키를

   이용해 생성한다.

 

장점

 - header와 payload를 가지고 signature를 생성하므로 데이터 위변조를 막을 수 있다.

 - 인증 정보에 대한 별도의 저장소가 필요없다. (서버 부하 X)

 

단점

 - payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보를 담으면 안된다.

 - 토큰을 탈취당하면 대처하기 어렵다.

 

보안 전략

1. 짧은 만료 기한 설정

 - 토큰의 만료 시간이 짧으면 탈취되더라도 금방 만료되기 때문에 피해를 최소화 할 수 있습니다. 하지만 사용자가 자주

   로그인 해야하는 불편함이 있습니다.