🤔 JWT 토큰과 쿠키에 대한 해결 방안

[saseungmin]

📌 해결 방안 및 결론

• 이틀 전에 파악한 문제가 원인이 아니였다.
• 이번 계기로 쿠키에 대해서 정말 많이 알게 되었다.
• 이틀 전에 파악한 원인은 말은 되는 것이였다. (링크 첨부)
  • 링크에 있는 답변에 보면 즉, 쿠키 도메인 설정에 하위 도메인 및 도메인이 같으면 가능한 것이다.

// 쿠키 도메인 설정이 다음과 같을 경우
Domain=.example.com

// 가능
foo.example.com
bar.example.com

// 불가
anather.anather.com

• 도메인과 쿠키에 관련된 내용은 링크의 블로그에 자세히 설명되어 있었다 (링크)
• 도메인이 같은 호스팅인 도메인은 읽기와 수정도 가능하고, 서브 도메인일 경우 읽기는 가능하지만 수정은 불가하고 3자 도메인일 경우 읽기 및 수정도 불가하다.
• 그래서 생각했던게 위와 같은 방법으로 프론트앤드 부분도 heroku로 변경하여 heroku에서 프론트부분을 배포하여 도메인을 맞춰줄려고 했었다. (front-end.herokuapp.com, back-end.herokuapp.com)
• 이 방법으로 프론트 부분을 다른 heroku로 배포해보았지만 여전히 안되었다. 그래서 무엇이 문제일까...? 고민을 하였고, 하나의 스택오버플로우 질문을 보게되었다. (참고)
• 질문은 내 상황과 같은 상황이였고, 답변을 확인해보았는데 불가는하다는 것이였다. 이유는 원래대로라면 기술적으로는 문제가 없지만, com은 공개 접미사 목록에 해당하기 때문에 안된다는 것이였다. Domain=.com일 경우, 결국 .herokuapp.com도 하위 도메인에 속하게 되고, 그니까 보안에 치명적인 위협을 끼칠 수 있다는 것이였다. 뭐야 그래서 어떻게 하라는거지..? 할 수 있는 방법은 있는거야?

🎯 생각한 세 가지 방법

• 첫 번째는 커스텀 도메인을 구입하는 방법이 떠올랐지만, 이 방법은 금전적인 문제로 패스
• 두 번째 방법은 하나의 도메인에서 해결할 수 있는 방법이였다. 즉, deploy.herokuapp.com이라는 하나의 도메인에서 백앤드 프론트앤드를 같이 배포하여 하는 방법이다. (api 호출시 deploy.herokuapp.com/api/auth/login, deploy.herokuapp.com/api/auth/register) 이 방법이 가장 좋아보였지만, 이미 백앤드 부분과 프론트앤드 부분을 다른 repository에 분리해놓았고, 같이 하나의 레포로 변경하면 프로젝트 구조 뿐만 아니라 모든 것을 다 바꿔줘야 했다. 즉, 설정해놓은 CI/CD 뿐만 아니라, test 설정 등등.. 다시 구조를 잡고 배포한다는 거 자체가 말도안된다고 생각이 들었다.
• 마지막으로 생각한 방법은 JWT 토큰만 프론트 앤드 쪽으로 response를 보낸 뒤, 프론트쪽에서 쿠키를 설정해주는 것이다. 프론트에서 쿠키를 설정하는 방법으로 가장 많이 사용되는 (universal-cookie)를 사용하게 되었다.

import Cookies from 'universal-cookie';
 
const cookies = new Cookies();
 
cookies.set('myCat', 'Pacman');
const pet = cookies.get('myCat');
console.log('Pacman');

• 이렇게 로그인 및 회원가입 후 받은 JWT를 쿠키에 set해주고, 백앤드로 보낼 때는 header에 담아 보내준 뒤 JWT가 유효한지를 검사해준다.
• 다음은 axios를 사용한 방법이다.

const client = axios.create(setPath(process.env.NODE_ENV));

client.interceptors.request.use((config) => {
  const token = getCookie('access_token');
  config.headers.Authorization = `Bearer ${token}` || '';

  return config;
});

export default client;

• 이제 백앤드에서 header에 토큰이 존재하는지 확인한 후 없으면 401을 반환하겠고, 토큰이 정상적인 토큰일 경우 유효하게 작업을 진행할 수 있을 것이다.

👉 한계점

• 결국 이 방법은 JWT 보안에 취약한 방법이다. 브라우저에 쿠키로 저장되는데, 클라이언트가 HTTP 요청을 보낼 때마다 자동으로 쿠키가 서버에 전송된다. 이 때, Javascript 내 글로벌 변수로 읽기 / 쓰기 접근이 가능하다.
• 때문에 XSS, CSRF 공격에 취약해질 수 밖에 없어진다. 왜냐면 인증 정보가 쿠키에 담겨 있는데 공격자?는 유저의 권한으로 정보를 가져오거나 액션을 수행할 수 있게 된다.
• secure, httpOnly 쿠키 저장 방식을 이용하면 된다. 이 방법을 이용하면 JavaScript에서 접근이 불가능하다. 하지만, 두개의 쿠키 옵션을 현재 다른 도메인에서 사용할 수 없다. secure 옵션을 사용하면 같은 도메인을 공유해야 한다. 그렇기 때문에 refreshToken을 사용하여 이 방법을 해결하려고 해도 결국엔 refreshToken을 secure, httpOnly 쿠키에 저장해야 되기 떄문에 refreshToken을 사용하는 건 불가능하다.
• 만약 refreshToken을 사용할 수 있으면 두 옵션의 쿠키로 저장하여 CSRF 공격을 방어하고, accessToken을 사용하여 로컬 변수로 저장한 뒤, API를 요청할 때 Authorization 헤더에 넣어 보내준다.
• 참고

Originally posted by @saseungmin in saseungmin/Recoil_ToDo#57 (comment)