localStorage | sessionStorage | Cookies

Web Storage

Web Storage는 두가지 방법으로 사용이 가능하다.

 

• localStorage : 각각의 출처에 대해 독립적인 저장공간을 제공하고 브라우저를 열었다 닫아도(페이지 세션이 유지되는 동안) 유지된다.
  • 유효기간 없이 데이터를 저장한다.
  • JavaScript를 이용하거나 브라우저 캐시또는 로컬 저장 데이터를 지워야만 사라진다.
  • 저장 공간이 가장크다. 
• sessionStorage : 위와 같지만 페이지 세션이 유지되지 않으면 사라진다.
  • 세션에 한정해서 데이터를 저장한다.
  • 데이터를 절대 서버로 전송하지 않는다.
  • 저장공간이 쿠키 보다 크다. (최대 5MB)

위 방식들은 window.sessionStorage 와 window.localStorage 로 접근하여 사용이 가능하다.

각각의 방식들은 Storage 객체를 사용하고 각각 출처 별로 독립적으로 사용이 가능하다.

 

localStorage, session에 저장한 자료는 페이지 프로토콜별로 구분한다. 특히 HTTP(http://example.com)로 방문한 페이지에서 저장한 데이터는 같은 페이지의 HTTPS(https://example.com)와는 다른 localStorage, sessionStorage에 저장된다.

키와 값은 항상 각 문자에 2바이트를 할당하는 UTF-16 DOMString의 형태로 저장된다. 객체와 마찬가지로 정수 키는 자동으로 문자열로 변환된다.

 

localStorage를 예로 들어보자.

//window는 생략이 가능하므로
localStorage.setItem('myCat', 'Tom');

const cat = localStorage.getItem('myCat');
//console.log(cat) : Tom

localStorage.removeItem('myCat');
// key인 'myCat'과 value인 'Tom'이 삭제됨

localStorage.clear()
// 로컬 스토리지의 전체 초기화

 

sessionStorage도 동일하게 사용이 가능하다.

 

---

Cookies

HTTP Cookie(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각이다.

브라우저에서는 그 데이터 조각(쿠키)을 저장해 놓았다가 같은 서버에 재 요청시 저장된 데이터를 함께 전송합니다. 

쿠키는 서버의 입장에서 요청이 동일한 브라우저에서 들어왔는지 여부를 판별할 때 주로 사용합니다. 이를 이용하면 사용자의 로그인 상태를 유지 할 수 있습니다. stateless HTTP 프로토콜에서 상태정보를 기억시켜주기 때문이다. 

 

쿠키는 주로 세가지 목적을 위해서 사용된다.

 

• 세션관리(Session management)
  • 서버에 저장해야할 로그인, 장바구니, 게임 스코어 등의 정보관리 (세션 안에서 이뤄져야할 데이터들)
• 개인화(Personalization)
  • 사용자 선호, 테마등의 세팅
• 트랙킹(Tracking)
  • 사용자의 행동을 분석하고 기록하는 용도

이전에는 쿠키를 클라이언트 측에 데이터를 저장하려는 용도로 사용하였습니다. 하지만 모든요청마다 데이터 헤더에 쿠키가 함께 감으로서 data connection 측면에서 성능저하(특히 모바일일 경우)가 발생 할 수 있다. 따라서 현재는 Web Storage API와 IndexdDB를 사용하면 된다. 

 

쿠키 생성

HTTP 요청을 수신할 때 서버는 응답과 함께 Set-Cookie 헤더를 전송할 수 있다. 쿠키는 보통 브라우저에 의해 저장되며 그후 쿠키는 같은서버에 의해 만들어진 요청들의 Cookie HTTP 헤더안에 포함되어 전송된다. 만료일 혹은 지속시간도 명시될 수 있어서 만료된 쿠키는 더이상 보내지지 않는다. 추가적으로 특정 도메인이나 경로 제한등을 설정해서 쿠키가 보내지는 것을 제어할 수 있다. 즉, 쿠키는 서버에서 만들어져 클라이언트로 보내어진다. 이후 클라이언트의 브라우저에서 관리된다.

 

Storage Inspector

저장된 쿠키 혹은 웹 페이지에서 사용할 수있는 스토리지 데이터들을 보려면 개발자 도구에서 Storage Inspector(스토리지 검사기)를 활성화 하고 스토리지 트리에서 쿠키 스토리지를 선택하면 된다.

 

구글 크롬의 경우 페이지 검사를 누르고 Application을 누르면 왼쪽 탭에 Local Storage, Sesstion Storage, Cookies, IndexedDB의 데이터가 나온다.

구글 크롬의 Storage Inspector

IndexedDB

파일이나 블롭등 많은양의 데이터를 클라이언트에 저장하기 위한 로우 레벨의 API이다.Web Storage는 적은양의 데이터를 클라이언트에 저장하는데 유용하지만 많은 양의 구조화된 데이터에는 적합하지 않다. 이렇게 구조화된 많은양의 데이터를 클라이언트에 저장할 때에는 IndexedDB가 유용하다. IndexedDB는 관계형 데이터베이스(RDBMS)와 같이 트랜젝션을 사용하는 데이터 베이스 시스템이다. 주로 키를 사용한 인덱스 데이터 테이블로서 사용자의 브라우저에 영구적으로 데이터를 저장하게 해주는 방법이다. 

 

stateless HTTP

동일한 연결(같은 브라우저와 같은 서버사이의)에서 연속적인 요청에서 두 요청사이에 아무런 연결고리가 없는 상황을 말한다.

이는 일관되게 웹 페이지를 이용하려는(쿠키나 로컬 스토리지등으로 유지된 정보들로) 사용자에게 큰 문제를 발생시킨다. 이를 위해서 HTTP 헤더에 쿠키를 넣어 해당 페이지를 상태저장 형태로 만들어 일관된 사용을 할 수 있게 한다.  

---

종합

셋 모두 클라이언트 상에서 key/value 쌍을 저장할 수 있는 메커니즘으로 value는 반드시 문자열이여야 한다.

모두 동일 출처 정책(SOP)을 갖기 때문에 다른 도메인에서 접근할 수 없다. 

 

	cookie	localStorage	sessionStorage
생성자	클라이언트/서버	클라이언트	클라이언트
지속시간	설정 여부에 따름	명시적으로 지울때까지	탭 / 윈도우 닫을 때까지
용량	5KB	5MB / 10MB	5MB
서버와의 통신	O	X	X
취약점	XSS / CSRF 공격	XSS 공격	XSS 공격

 

CSRF(Cross Site Request Forgery) 크로스 사이트 요청위조

 

아래의 예를 살펴보자

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

만약 사용자의 은행 사이트에 대한 로그인 쿠키 정보가 살아있고(사용자가 해당 페이지의 수정권한을 갖고 있고) 별 다른 검증 절차가 존재하지 않는다면 위 HTML을 로드 하자마자 돈이 전송 될 것이다. 위의 HTML문서가 악의적인 코드를 갖고 있다면 별 수 없이 당하게 된다.

이러한 일들이 벌어지는 것을 방지하기 위해서는 RESTful API를 구현하거나, 보안토큰을 추가해야한다.

 

XSS(Cross site scripting) 

 

보안에 취약한 사이트로 부터 피해자가 악성 스크립트 및 리소스들을 주입당해서 이뤄진다. 보통 피해자가 악성 리소스를 스스로 건들여 주입당한다. 이러한 악성 스크립트들은 보통 피해자의 브라우저를 공격자가 컨트롤하는 페이지로 바꾸거나 다른 HTML문서나 실행파일을 넣어버리도 하는데 기본적으로 페이지가 가지고 있는 사용자의 고유 쿠키 정보나 세션정보를 공격자에게 보내는 것을 포함합니다.

XSS를 기반으로하는 다양한 공격들은 보통 무궁무진하게 제한이 없다. 이러한 공격은 웹 앱이 충분한 유효성 검사 또는 인코딩을 사용하지 않는 경우 일어날 수 있다.

 

---

동일 출처 정책(SOP : Same Origin Policy)

어떠한 문서나 스크립트가 다른 프로토콜 / 포트 / 호스트에 있는 리소스를 사용하는 것을 제한하는 정책, 예를 들어 다음과 같은 사이트에서 리소스를 다른 곳으로 요청한다고 하자

http://website.com/ex/ex.html

 

리소스 요청	허용 여부
http://website.com/ex/	성공
http://website.com/ex1/	성공
http://website.com:81/ex/ex.html	실패, 포트가 다름
http://wwebsite.com/ex/	실패, 호스트가 다름
https://website.com/ex/ex.html	실패, 프로토콜 다름

호스트, 프로토콜, 포트 셋중에 하나라도 다르면 리소스 요청에 실패한다.

 

---

참고

 

github.com/baeharam/Must-Know-About-Frontend/blob/master/Notes/html/web-storage-api.md

baeharam/Must-Know-About-Frontend

 

developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#cross-site_scripting_xss

Types of attacks - Web security | MDN

developer.mozilla.org/ko/docs/Web/HTTP/Cookies

HTTP 쿠키 - HTTP | MDN

developers.google.com/web/tools/chrome-devtools/storage/localstorage

View And Edit Local Storage With Chrome DevTools  |  Google Developers

developer.mozilla.org/ko/docs/Web/API/Web_Storage_API

Web Storage API - Web API | MDN

developer.mozilla.org/en-US/docs/Web/HTTP/Overview#http_is_stateless_but_not_sessionless

An overview of HTTP - HTTP | MDN

developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

IndexedDB API - Web APIs | MDN