[TIL]240510 Access Token과 Refresh Token 저장 위치

Access Token과 Refresh Token을 어디에 저장해야 할까?

현재

• Access Token과 Refresh Token을 헤더에 담아 넘기고, LocalStorage에 저장하는 방식을 사용중이다.

→ 이 방법이 보안에 취약하다는 글을 발견했다.

토큰을 저장하기 위한 일반적으로 두가지 방식이 존재한다. 첫 번째는 LocalStorage 에 저장하는 방식이고, 두 번째는 Cookies에 저장하는 방식이다.

대부분의 사람들은 쿠키에 저장하는 방식이 더 안전하다고 말한다.

LocalStorage vs Cookies

LocalStorage

장점

• 로컬 스토리지의 장점은 편리하다.
• LocalStorage에 저장된 access token은 Authorization Bearer ${access_token}과 같은 형식으로 HTTP header에 넣어서 사용해야 한다.

단점

• XSS 공격에 취약하다.
• XSS 공격은 당신의 웹사이트에서 공격자가 JavaScript를 실행할 수 있을때 발생한다. 이는 localStorage에 저장되어있는 access token을 공격자가 탈취할 수 있다는 말이다. XSS 공격은 React, Vue, jQuery, Google Analytics 등과 같은 웹사이트에 포함된 third-party JavaScript 코드에 의해서 발생할 수 있다. 하지만 third-party 라이브러리를 당신의 웹사이트에 포함하지 않는 것은 거의 불가능하다.

• XSS(Cross Site Scripting) 공격 : 공격자가 의도하는 악의적인 js 코드를 피해자 웹 브라우저에서 실행시키는 것이다. XSS 라고 불리는 이유는 이미 CSS 약자가 있기 때문이다.

Cookies

장점

• 쿠키는 javascript로 접근이 불가능하다. 그래서 로컬스토리지 만큼 XSS 공격에 취약하지 않다.
• 만약 공격자가 JavaScript를 사이트에서 실행한다고 했을 때, cookie의 httpOnly나 secure 옵션을 사용한다면 쿠키는 JavaScript의 접근에 안전해진다. 그리고 쿠키는 자동으로 모든 HTTP 요청에 포함되어 보내진다.

단점

• 일부 케이스에 대해서는 당신의 토큰을 쿠키에 저장하지 못할 수 있다.
• 쿠키는 4KB의 size limit을 가진다. 그러므로 만약 4KB가 넘는 데이터를 가지는 JWT 토큰을 사용한다면 쿠키는 적절한 선택지가 아닐 수도 있다. 만약 API 서버가 쿠키를 사용할 수 없거나 API의 요청에서 access 토큰을 authorization header에 넣어줘야 한다면 쿠키를 사용할 수 없을 것이다.

⇒ 쿠키가 취약점이 있음에도 불구하고 로컬 스토리지보다 더 선호된다.

• 로컬 스토리지와 쿠키 둘다 XSS 공격에는 취약하다. 그러나 쿠키에서 httpOnly 플래그를 사용한다면 쿠키가 조금 더 공격자가 접근하기 어렵다.
• 쿠키는 CSRF 공격에 취약하다. 그러나 samasite 플래그와 anti-CSRF tokens 을 사용하면 어느정도 예방이 가능하다.

• CSRF 공격 : 유저가 의도하지 않은 요청을 하도록 만드는 공격이다.

→ 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 해서 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법이다.