쿠키와 세션, 웹 스토리지

MyeonghoonNam·2021년 8월 15일
세션웹 스토리지쿠키
0
post-custom-banner

브라우저가 사용자의 설정을 기억하는 방법에는 무엇이 있는지 중점적으로 알아보자.

HTTP 통신

  • HTTP 요청은 기본적으로 상태가 존재하지 않는다. 즉, 항상 단발성이다.

  • 상태가 존재하지 않기 때문에 서버는 어떤 브라우저에서 요청이 온 것인지 알 수 없다.

  • 이 때 요청 헤더에 쿠키를 담으면 서버가 쿠키를 읽어 어디서 온 요청인지 알 수 있다.

Cookie

img

  • 클라이언트에서 저장, 관리하는 데이터로 브라우저를 닫아도 데이터를 유지할 수 있다.

  • 서버에서 Set-Cookie를 응답 헤더와 함께 보내주면 클라이언트는 쿠키를 받아서 저장한다.

  • 클라이언트에서 자체적인 조작도 가능하다.

  • 각 상태에 수명을 정할 수 있다.


  • Set-Cookie : 키=값; 옵션 과 같은 형태

  • 응답 헤더에 담으면 브라우저가 알아서 저장한다.

  • 각 데이터에는 여러 옵션이 존재한다.

    • Expires : 쿠키 만료 날짜를 지정한다.

    • Secure : HTTPS 에서만 쿠키를 전송한다.

    • HttpOnly : JavaScript 에서 쿠키에 접근 못하도록 막는다. 이로인해 XSS 공격을 막을 수 있다.

      XSS (크로스사이트 스크립트, 크로스사이트 스크립팅, Cross Site Scripting)

      검증되지 않은 입력 값으로 사용자의 웹 브라우저에서 의도하지 않은 악성 스크립트가 실행되게 하는 공격

    • Max-Age : 쿠키 수명을 정하며, 이 때 Expires 옵션은 무시된다.

    • Domain : 도메인이 일치하는 요청만 쿠키가 전송된다.

    • Path : 패스와 일치하는 요청만 쿠키가 전송된다.


Cookie의 취약점

  • XSS(Cross Site Scripting) 공격을 당할 수 있다.

  • JavaScript를 이용한 악의적인 사용자가 다른 사용자의 쿠키 값을 탈취 할 수 있다.

  • 쿠키를 암호화 하지 않고 보내면 쿠키 값을 중간에 탈취 당할 수 도 있다.

  • HTTPS를 이용하여 위의 문제점을 해결할 수 있다.

  • HTTP 요청시 헤더에 쿠키가 같이 포함되어 있으므로 쿠키 사이즈가 커지면 HTTP 요청 크기 역시 커지게 된다.

Session

클라이언트가 쿠키를 서버에게 보내어도 서버는 쿠키의 주인이 누구인지 알 지 못한다. 이 때 사용되어 지는 것이 Session이다.

  • HTTP Session Id를 식별자로 사용자를 구분한다.

  • 클라이언트는 HTTP Session Id를 쿠키 형태로 저장한다.

  • 서버 자체적으로 기록하고 관리한다.

img

Session의 취약점

Session은 서버에 파일로 저장이 되어 있다. 만약 사용자가 엄청나게 많다면 방대한 파일의 양이 문제가 될 수 있고, 서버가 만약 2대로 Session들을 관리한다면 각 인증 정보가 분리되어 있기 대문에 제대로 된 정보를 반환하지 못할 수 있다.

그래서 서버와 클라이언트 사이의 인증은 별도 토큰을 사용하고 쿠키는 클라이언트 자체적인 지속적인 데이터 관리 용도로 많이 사용되고 있다.

이러한 상황 속에 새롭게 등장한게 웹 스토리지이다.

웹 스토리지

Cookie 대신 로컬 데이터를 관리하는 새로운 표준이 바로 웹 스토리지 이다.

  • 클라이언트에 데이터를 저장하기 위한 새로운 방법

  • HTML5 부터 등장하였다.

  • Cookie에서 하기 힘든 것들을 지원하기 위해 등장하였다.

  • 로컬 스토리지와 세션 스토리지가 존재한다.


로컬 스토리지

  • 데이터를 저장하면 반영구적으로 데이터가 저장된다.

  • 브라우저를 종료해도 계속해서 데이터가 남아있다.

  • 저장했던 도메인과 이용하는 도메인이 다른 경우엔 접근이 불가하다. 반대로 말하면 도메인만 같다면 여러 탭에서 같은 Storage를 공유한다.

  • Cookie와 마찬가지로 Key-Value 형태로 저장한다.


세션 스토리지

  • 새 창을 생성할 때 마다 개별적으로 저장되는 데이터를 관리한다.

  • 브라우저를 닫는 순간 그 창의 데이터는 사라진다.

  • 같은 도메인이어도 세션이 다르면 데이터에 접근할 수 없다. (같은 도메인 다른 창)

  • Cookie와 마찬가지로 Key-Value 형태로 저장한다.

JavaScript로 간단 구현 비교

// 쿠키 관리는 String으로 하며 불편하다.
document.cookie = 'key1=value1; key2=value2';
console.log(document.cookie);

// 로컬 스토리지
// 데이터를 저장한다.
localStorage.setItem('name', 'hoon');
console.log(localStorage.getItem('name')); // hoon

// 데이터를 지운다.
localStorage.removeItem('name');

// 데이터를 전부 지운다.
localStorage.clear();

// 세션 스토리지
sessionStorage.setItem('name', 'hoon');
console.log(sessionStorage.getItem('name')); // hoon

// 데이터를 지운다.
sessionStorage.removeItem('name');

// 데이터를 전부 지운다.
sessionStorage.clear();

개발자 도구에서 Application 탭에서 웹 스토리지와 쿠키들을 확인하며 비교해보자.

IndexedDB

JSON 객체가 모여있는 트랜잭셔널 로컬 데이터베이스를 위해 W3C 가 권고한 웹 브라우저 표준 인터페이스의 하나이다.

웹 브라우저는 데이터베이스에서 영속적인 데이터를 모아서 저장할 수 있다. 다음과 같은 특징이 존재합니다.

  • 간단한 javascript API만으로도 database 조작이 가능합니다.

  • Key-Value 로 데이터를 관리합니다.

  • HTML, CSS, img 와 같은 static 파일보다는 JSON, XML data 등과 같이 자주 바뀌는 data를 저장하는데 주로 사용됩니다.

  • Transaction 처리가 가능합니다. (commit & rollback)

  • browser가 제공하는 local storage와 session storage는 synchronously 하게 접근되기 때문에 service worker가 사용할 수 없지만, indexedDB는 asynchronously 하게 접근될 수 있기 때문에 service worker가 사용할 수 있습니다.

  • 하나의 App에 하나의 IndexedDB를 구성하는 것이 일반적입니다.


웹 스토리지와 비교

IndexedDB는 많은 데이터를 저장하고, 이를 Index 를 이용하여, 빠르게 검색할 수 있게 설계 되었다.

웹 스토리지 인 Local Storage 와 Session Storage 는 최대 10MB 만 저장이 가능하며, 오직 String 형태만 저장이 가능하다. 하지만 IndexedDB 는 javascript 가 이해하는 어떠한 값이라도 모두 저장할 수 있다.

IndexedDB 는 용량 제한은 특별히 없으나, HDD 저장소 상태 나 브라우저의 상태에 따라서 달라 질 수 있다.

시크릿 모드에서 IndexedDB, Storage 를 사용하면, 값은 저장되지 않고 브라우저 종료시 사라진다.

작은 규모의 데이터는 Storage 를 사용하는것이 좋지만, 큰 데이터는 IndexedDB 를 사용하는 것이 여러모로 유리하다.


참고자료

profile
MyeonghoonNam
꾸준히 성장하는 개발자를 목표로 합니다.
이전 포스트

유니코드

다음 포스트

TIL - Day 11

post-custom-banner

0개의 댓글