현재 사용하고 있는 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토큰을 어디에 저장하는 것이 좋을까?
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 |