[ASAC 06] 세션과 JWT, CORS 관련 질문 정리

이 글은 ASAC 06기를 수강하며 강의 자료 참고 및 추가 자료 수집을 통해 작성된 글입니다.

세션과 JWT 차이점

들어가기 앞서

• Session은 서버 측에 저장되는 정보이다.
• Cookie는 클라이언트 측(브라우저)에 저장되는 정보이다.
• Session만 사용하고 쿠키를 사용하지 않는 것이 아니다. 세션과 쿠키는 함께 사용된다.

 

세션

• 사용자의 모든 인증 정보(유저정보 + 만료시간 + 세션 ID)들을 가지고 있으며, 세션 사용 시 클라이언트는 쿠키로 세션 ID 및 만료 시간을 전달 받는다.
• 세션 정보는 서버 측에 저장된다.
• 세션 ID는 특별한 정보를 함의하지 않는 UUID이다.
• 세션 정보는 서버 측에 저장되기 때문에 세션을 사용한 인증 및 세션 관리를 위해서 서버 측 부하가 커진다.
• 세션을 서버에 저장한다면, SPoF 문제가 발생할 수 있기 때문에 세션 관리를 위한 스토리지를 따로 두는 것이 좋다.
• 세션을 사용한 인증에서는 세션을 조회하여 세션 ID와 대조 후 인증을 수행하기 때문에, 조회 성능이 곧 인증 성능이 된다.
• 조회 성능을 높이고자 Redis와 같은 메모리 기반(빠르다)의 DB를 사용하여 세션을 저장 및 관리하지만, 메모리 기반이기 때문에 비용이 매우 비싸다.

JWT

• JWT는 세션과 달리 사용자의 모든 정보가 아닌 노출되도 상관 없는 정보(역할과 이름 정도의 rough한 정보들)들과 인증 완료를 함의한다.
• JWT의 등장 배경에서 생각해보면, 서버의 부하를 줄이고 브라우저로 부하를 분산하기 위함이라는 것을 떠올려 볼 수 있다.
• 즉, JWT는 관리를 위해 서버 DB가 필요가 없다. 일단 JWT를 가져오면 이 사람을 의심하지 않고 권한을 주게 된다.
• 그래서 JWT는 탈취되는 순간 매우 치명적이다. 안전한 관리가 필요하다.
• 주로 Access Token, Refresh Token 두 가지 JWT를 두고 관리한다.
  • Access Token : 짧은 유효 기간. 인증을 위해 사용됨.
  • Refrehs Token : 긴 유효 기간. Access Token의 재발급을 위해서 사용됨.
• Access Token은 짧은 유효기간을 가지기 때문에, 탈취되더라도 위험성이 크지 않다.
• 그러나 Refresh Token은 긴 유효기간을 가지며, 서버에서 탈취 사실을 알기 힘들다.

Refresh Token을 안전하게 사용하는 방법

탈취 자체를 막는 것은 어려우므로 다음과 같이 Refresh Token을 관리하는 것이 권장된다.

• Refresh Token의 유효기간을 짧게 설정한다.
• Access Token 재발급 시, Refresh Token도 함께 재발급하여 전달.
• IP 주소, 기기 정보 확인 등의 추가 정보를 함께 사용한다.
• 로그아웃 시 Refresh Token 무효화

결론

JWT = stateless

세션 = stateful

 

CORS와 same-site 차이

CORS

• CSRF(Cross Site Request Forgery)는 비의도적 요청(제 3자가 심어놓은 script에 의한 악의적 요청)으로 하는 공격이다.
• CORS는 CSRF를 부분적으로 방지하는 정책이다.
  • => 비의도적 요청을 발생시키고 싶지 않기 때문에 CSRF를 애당초 보내지 않도록 막는 것이다.

same-site

• TLD + SLD가 같으면 퍼스트 파티 쿠키. 다르면 서드 파티 쿠키.
• same-site 설정 = 서드 파티 쿠키를 안 보내겠다. (현재 브라우저는 default가 서드 파티 쿠키를 안 보내는 것.)
• same-site는 브라우저의 정책이므로, 서버에서 서드파티 쿠키를 사용해 google.api로 요청이 가능하다.

 

CORS Blocking은 왜 브라우저에서 하는가?

• 똑같은 도메인이더라도 CSRF 취약성은 서버가 아닌 웹 브라우저에만 있다.
  • JS는 스크립트의 외부 주입이 가능하다. (Java -> 해커에게 취약하지 않다.)
  • 서버 간 요청은 브라우저처럼 인증 정보를 자동으로 포함하지 않는다. -> CORS가 불필요
• 만약에 "서버"가 막는다면, WB와 WS는 둘 다 막힌다.
  • WS에서의 요청은 의도된 요청이고, CSRF 이슈가 없음에도 막힐 수 있다.
• 결론적으로, 서버가 아닌 브라우저에서 CORS Blocking을 해야한다.
• 또한, 단 하나라도 의도적 요청이 필요하다면, CORS 허용하는 게 좋다. (허용이 필요하다.)

 

XSS와 CSRF 차이

• XSS 공격과 CSRF는 브라우저를 대상으로 하는 공격이라는 공통점을 가진다.
• XSS는 사용자의 인증된 세션을 사용하는 공격이다.
  • 사용자가 특정 사이트를 신뢰하는 것을 이용
• CSRF는 인증 세션이 없더라도 공격이 가능하다.
  • 웹 애플리케이션이 인증된 사용자의 요청을 신뢰하는 것을 이용
• XSS는 사용자로부터 스크립트가 실행된다.
• CSRF는 서버에서 스크립트가 실행된다.
• XSS는 사용자 정보 탈취가 목적임
• CSRF는 요청 위조로 특정 행위를 하는 것이 목적임

https://nordvpn.com/ko/blog/csrf/?srsltid=AfmBOorJ_fVMmXbJDkiVt_pgR5FuCT4dVd-MZrrK_a4jw_43AHY8J5J2

크로스 사이트 요청 위조(CSRF)의 의미 | NordVPN