목차
Stouter
Stouter

백엔드 개발자입니다.

토큰 인증 과정에서 취약성 개선을 위한 고민

항상 기계적으로 구현했던 인증 부분에 관해서 어느날 의문이 들었다. 우리는 어떤 공격을 방어하기 위해 이러한 절차들을 마련해둔걸까? 과연 JWT 토큰 기반의 인증은 안전한걸까? 정리해보자.

웹 취약성

CSRF

  • 기존 사이트와 유사한 피싱사이트를 통해 피해 유저의 권한을 도용하여 공격하는 방식
  • 해커가 moonjin.site 로 form을 만들어 password/change 같은 API 요청을 심어놓을 경우, 사용자는 패스워드를 변경당할 수 있다.

Untitled

해결법

  1. Referrer 체크
    1. Host 와 Referrer가 같은 지 확인하여 다르면 반송
  2. API 설계 시 사용자의 정보를 변경하거나, token을 발급하는 등의 중요한 API는 각별히 주의하자.
  • 참고 자료

CSRF(Cross-Site Request Forgery) 공격과 방어


XSS

  • Javascript 코드를 삽입해서 임의적으로 데이터를 탈취하는 방식의 공격

해결법

  • cookie → httponly 쿠키 : 브라우저상에서 쿠키 탈취 제한


Cookies

sercure

  • 쿠키가 Http로 전달되면 감청 등과 같이 해커가 가로챌 수 있음
  • https는 해당 쿠키를 암호화하여 보내는 방식으로 쿠키를 감청 불가
  • 따라서 secure 세팅이 되어 있다면, http 요청에는 쿠키를 담지 않음.

httponly

  • 브라우저에서 Cookie를 접근할 수 없도록 하는 설정 → 코드로 접근 불가능
  • 이를 통해 XSS 및 CSS 공격을 막을 수 있다.

[Web] HTTP Only와 Secure Cookie 이해하기


우리가 사용하는 인증 방식

토큰 종류

  • accessToken
  • refreshToken

방법 : DB에 refresh 토큰과 함께 유저의 IP를 저장

  • AccessToken + RefreshToken을 함께 저장
  • RefreshToken을 활용하여 AccessToken을 재발급할 때, 원래의 IP와 다른 곳에서 접속했다면,
    • 일단 발급은 시키되, 사용자에게 이를 알린다.
    • 사용자가 본인이 로그인한 것이 아니라고 한다면, refreshToken을 삭제한다.
      • 이를 다시 얻으려면 로그인 해야한다. (사용자만 가능한 것)
  • 단점
    • 메일이 너무 자주 와서 UX적으로 불편 가능

refresh token 도입기

고민

Q. ATK와 RTK를 같은 쿠키에 담는게 의미가 있나?

  • RTK는 브라우저의 스토리지 공간에 저장하고, ATK와 함께 전달되지 않도록 하는게 중요한 것 같다.
  • 아니면 ATK를 API Header에 넣고, RTK를 쿠키에 넣는것도 좋은 방법인 것 같다.

우리가 선택한 방식

  • accessToken → cookie
  • refreshToken → cookie (ATK가 없을 시에만 전송)
  • 메일 전송과 같은 중요도가 높은 기능 → alert 메일 전송