로그인시 토큰을 어디에 저장할까

Jaemin Jung·2022년 6월 22일
0

고민의 시작


과업에서 로그인 인증은 access 토큰을 이용해서 진행한다.
처음에 이 토큰을 로컬 스토리지에 저장시키는 방식으로 구현 했는데,
이에 대해 좀 더 좋은 방향으로 먼저 찾아보는게 좋을거 같아 구글링을 해보았다.
정해진 답은 없었다. 보안의 정도와 서비스 기획 방식에 따라 달라진다.
토큰 저장소는 쿠키 vs 로컬 스토리지 / 세션 스토리지 두 경우로 나누어 볼 수 있다.

웹 스토리지 (local, session)


공통점

  • 브라우저(클라이언트)의 데이터 저장소
  • 데이터가 서버로 전송되지 않음
  • 데이터는 키-값의 데이터 형태로 저장됨
  • 서버에서 접근할 수 없다.

차이점

  • 로컬 스토리지는 사용자가 데이터를 지우지 않는 이상 영구 보관됨
  • 세션 스토리지는 세션을 닫을 경우 데이터가 제거됨
  • 로컬 스토리지는 도메인 별로 데터를 공유,
  • 세션 스토리지는 세션(탭, 브라우저) 별로 데이터를 공유함
    (같은 도메인일지라도 다른 세션일 경우 데이터는 개별로 저장됨)

장점

  • 구현이 쉽다.
  • 쿠키의 저장용량(약 4KB)보다 큰 저장용량(5MB)를 가짐
  • 로컬 스토리지 사용시 자동 로그인에 적합함

단점

  • XSS(Cross Site Scripting) 공격에 취약
    공격자(해커)가 클라이언트 브라우저에 Javascript를 삽입해 실행하는 공격이다. 예를들어 공격자가 <input>을 통해 Javascript를 서버로 전송해 서버에서 스크립트를 실행하거나, url에 Javascript를 적어 클라이언트에서 스크립트 실행이 가능하다면 공격자가 사이트에 스크립트를 삽입해 XSS 공격을 할 수 있다. 이때 공격자는 Javascript를 통해 사이트의 글로벌 변숫값을 가져오거나 그 값을 이용해 사이트인 척 API 콜을 요청할 수도 있다. 다시 말하면 공격자의 코드가 내 사이트의 로직인 척 행동할 수 있다는 거다.
    한마디로 해커가 storage에 접근만 한다면 토큰 탈취됨

쿠키


  • http의 stateless 특성을 보완하기 위해 등장
  • 서버에서 클라이언트에 값을 저장하고 읽을 수 있도록 해주는 도구
  • 자동으로 request header에 포함된다.
  • 매우 작은 저장공간을 가짐
  • 서버에서 지정한 기간이 지나게 되면 삭제된다.
  • HttpOnly 설정을 이용하여 사용자가 제어할 수 없도록 만들 수 있다.

장점

  • XSS 해킹 문제를 해결 할 수 있다.
  • Secure 옵션을 주면 쿠키가 HTTPS로만 전송되기 때문에 보안 수준을 높힐 수 있다.

단점

  • 쿠키를 사용하기 위해 서버에서 별도의 세팅이 필요하다.
  • CSRF 공격의 위험이 있다.

보안 취약점

  • CSRF(Cross Site Request Forgery) 공격
    공격자가 다른 사이트에서 우리 사이트의 API 콜을 요청해 실행하는 공격이다. API 콜을 요청할 수 있는 클라이언트 도메인이 누구인지 서버에서 통제하고 있지 않다면 CSRF가 가능한데, 이때 공격자가 클라이언트에 저장된 유저 인증정보를 서버에 보낼 수 있다면, 제대로 로그인한 것처럼 유저의 정보를 변경하거나 유저만 가능한 액션들을 수행할 수 있다. 예를 들어 CSRF에 취약한 은행 사이트가 있다면 로그인한 척 계좌 비밀번호를 바꾸거나 송금을 보낼 수 있는 것이다.

--> CORS를 허용한 URL 에서 보내는 요청이 아니면 막는 방법을 통해서 해결

쿠키를 사용하기 위한 세팅

HttpOnly

  • HttpOnly 옵션을 이용하면 브라우저만 cookie 정보를 읽을 수 있음.
  • 자바스크립트(코드)에서도 cookie의 정보를 읽을 수 없기 때문에 보안에 좋다.

SameSite

  • 서로 다른 도메인에서의 쿠키전송에 관한 보안.
    none
  • 도메인이 다른 경우(cross-origin)에도 브라우저가 쿠키를 포함해서 요청을 보낼 수 있음.
  • cross-origin이라면 none 만이 유일하게 동작
    strict
  • 도메인이 다른 경우(cross-origin) 브라우저가 쿠키를 포함하지 않음.
    lax
  • strict과 비슷하지만, 다른 도메인 내에서 same-origin의 도메인 주소를 가리키는 링크를 클릭한 경우, 해당 요청에 대해서만 쿠키를 포함해줌.

Secure

true

  • SameSite='none' 일 경우 true 여야 한다.
  • https 프로토콜을 사용할 때만 쿠키를 request header에 담겨서 서버에 보내지고 http 프로토콜일 때는 쿠키가 담겨지지 않음.
  • 다만, localhost에서는 예외적으로 허용

Domain

MaxAge

  • 쿠키의 만료기간을 지정한다.
  • 다만 단위가 ms이기 때문에 1000을 곱해준다.

어디에 저장하는게 좋을까?

웹 스토리지는 JavaScript로 쉽게 접근이 가능하기 때문에 XSS의 측면에서 볼 때 좋지 않다.
HttpOnly 옵션을 통해 JavaScript를 차단할 수 있는 Cookie가 조금 더 보안에 좋다고 생각한다.

보안이 크게 중요하지 않다면 웹스토리지가 나쁘지 않은 선택이 될 수 있다.
쿠키와 다르게 반 영구적으로 많은 저장공간을 사용할 수 있기 때문

보안의 안정성을 중요시 한다면 쿠키가 좀 더 보안적인 측면에서 강하기 때문에 쿠키를 사용하는게 좋아보인다.

가장 보편적으로 사용하는 토큰 핸들링

profile
내가 보려고 쓰는 블로그

0개의 댓글