본문 바로가기

공부기록/API

[JWT token] 어디에 저장해야 할까?

현재 사용하고 있는 access token의 유효시간은 15분이다. 

시간을 늘리는 방법도 가능하지만, 

탈취되어버리면 해커로부터의 공격을 막을 수 없게 된다. 

 

그러나 유효시간이 15분밖에 되지 않는다면 

사용자 경험이 좋지 않아질 것이다. 

이때 필요한 것이 refresh token이다. 

 

먼저 각 토큰을 저장할 때 취약점을 살펴보기로 한다. 

access token을 어디에 저장하느냐이다. 

 

 

JWT토큰을 저장할 때

 

- 로컬스토리지에 저장 :

자바스크립트로 접근이 쉽기 때문에 XSS 공격에 취약하고 보안상 문제 소지가 많다. 

브라우저에 저장된 중요 정보들을 탈취 당할 가능성이 있다.

 

- 쿠키에 저장 :

자동으로 서버에 보내지므로 편리하다. 

단점 : CSRF공격에 취약하다. 4KB이상일 때는 

HTTP Only옵션을 걸면 javascript로 접근 불가 

Secure옵션을 걸면 HTTPS가 적용되지 않은 이미지등으로 인해 쿠키를 탈취당하지 않음

 

 

 

XSS공격이란? 

XSS는 cross-site scripting의 줄임말이다. 

XSS는 공격자가 유저와 취약한 응용프로그램의 상호작용을 손상시킬 수 있는 웹 보안 취약점이다.

공격자가 same origin 정책을 우회할 수 있게 만드는 것인데, 그 정책은 다른 웹사이트들과 각각 분리를 하기 위한 것이다. 

Cross-site scripting 취약성은 일반적으로 공격자가 피해 유저처럼 보이게 만들며, 그 유저가 할 수 있는 행동들을 하고, 

그 유저의 데이터에 접근할 수 있게 만든다. 

만약 피해 유저가 애플리케이션 내에 기밀 접근권을 가지고 있다면 공격자는 애플리케이션의 기능과 데이터의 모든 통제를 

가질 수 있게 될 것이다. 

https://portswigger.net/web-security/cross-site-scripting

 

What is cross-site scripting (XSS) and how to prevent it? | Web Security Academy

In this section, we'll explain what cross-site scripting is, describe the different varieties of cross-site scripting vulnerabilities, and spell out how to ...

portswigger.net

 

CSRF공격이란? 

https://portswigger.net/web-security/csrf

 

What is CSRF (Cross-site request forgery)? Tutorial & Examples | Web Security Academy

In this section, we'll explain what cross-site request forgery is, describe some examples of common CSRF vulnerabilities, and explain how to prevent CSRF ...

portswigger.net

Cross-site request forgery의 줄임말로, 웹 보안 취약점이다.

공격자가 유저로 하여금 의도치 않은 행동을 하도록 유도할 수 있게 한다. 

CSRF는 공격자가 부분적으로 same origin 정책을 피할 수 있게 만든다. 

same origin 정책은 다른 사이트들이 서로를 간섭하지 못하도록 방지하기 위해 고안된 정책이다. 

 

CSRF의 영향은?

공격자가 CSRF 공격에 성공하면, 공격자는 피해 유저의 의도와는 다른 행동을 하게 만든다. 

예를들어 그 계정의 이메일 주소, 비밀번호를 변경하거나 자금을 송금할 수 있을 것이다. 

그 행동의 본질에 비추어볼때, 공격자는 유저의 계정을 완벽한 통제가 가능해 질 것이다. 

만약 위태로워진 유저가 애플리케이션의 기밀 접근권을 가지고 있다면 공격자는 

해당 애플리케이션의 데이터와 기능에 대해 완전한 통제를 가질 수 있게 될 것이다. 

 

 

  CSRF  방어 :

쓰기/변경이 가능한 POST, PATCH, DELETE Method에만 적용하면 됩니다

 

 

Security Token사용 - 사용자의 세션에 임의의 난수값을 저장하고 사용자 요청마다 난수값을 포함시켜 전송 

이후 Back-end단에서 요청을 받을 때마다 세션에 저장된 토큰값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증 

 

Referrer 사용 - Back-end단에서 request의 referrer를 확인하여 domain이 일치하는지 검증하는 방법

(이부분들은 다 백엔드에서 프레임워크에 기본 값으로 포함되어있으므로 

걱정하지 않아도 되겠다. )

 

 

 

https://prolog.techcourse.co.kr/studylogs/2272

 

우아한테크코스 학습로그 저장소

우아한테크코스 크루들이 배운 내용을 기록하는 학습로그 저장소입니다.

prolog.techcourse.co.kr

 

JWT토큰을 어디에 저장하는 것이 좋을까?

 

https://dev.to/cotter/localstorage-vs-cookies-all-you-need-to-know-about-storing-jwt-tokens-securely-in-the-front-end-15id

 

access token은 메모리에 저장하고, refresh token은 httpOnly 쿠키에 저장하는 것이 제일 안전한 방법이라고 쓰여있다. 

 

1. 유저임을 증명받는다면 권한서버는 access token과 refresh token을 줄 것이다. access token은 response body 에 포함되어있을 것이며 refresh token은 쿠키에 포함될 것이다. 

리프레쉬 토큰 쿠키의 셋업 : 

 - httpOnly플래그 쓰기: javascript가 읽지 못하도록  

 - secure=true 플래그 쓰기: HTTPS를 통해서만 보낼 수 있도록

 - SameSite=strict 플래그 쓰기 : 어느때나 CSRF를 방지할수 있도록 

   이것은 권한 서버가 프론트엔드와 같은 사이트를 가지고 있을 때 사용할 수 있다. 

   만약 이러한 케이스가 아니라면 권한 서버는 백엔드에  CORS 헤더를 설정해야 한다. 

   혹은 refresh token요청을 증명된 웹사이트에 의해서만 할 수 있도록 다른 메소드를 사용해야 한다. 

 

 

2. access token을 메모리에 저장하기. 그러면 새로고침하면 사라질 것이지만 그래서 refresh token을 쿠키에 저장하는 것이다.

3. access token이 사라지거나 파기되었을 때, /refresh_token엔드포인트를 쳐서(?) 

1번에서 쿠키에 저장된 refresh토큰이 요청으로 보내질 것이다. 

이는 JWT 토큰이 4KB 보다 커도 가능하게 되는 것이다. 

'공부기록 > API' 카테고리의 다른 글

[422에러] content-type  (0) 2023.01.27
[API] 리액트에서 카카오 지도 활용해보기  (0) 2023.01.12
[API] 카카오 API Key 발급받기  (0) 2023.01.12