로컬 저장소와 쿠키

질문자 :Gio Borje

모든 쿠키가 동일한 기능을 가지고 있는 것처럼 보이므로 모든 쿠키를 로컬 저장소로 이동하여 내 웹사이트의 로드 시간을 줄이고 싶습니다. 명백한 호환성 문제를 제외하고 쿠키 기능을 대체하기 위해 로컬 저장소를 사용할 때 장단점(특히 성능 면에서)이 있습니까?

쿠키와 로컬 저장소는 다른 용도로 사용됩니다. 쿠키는 주로 서버 측 읽기용이며 로컬 저장소는 클라이언트 측 에서만 읽을 수 있습니다. 따라서 문제는 앱에서 누가 이 데이터를 필요로 합니까? 클라이언트 또는 서버 중 무엇입니까?

클라이언트(JavaScript)라면 반드시 전환하십시오. 각 HTTP 헤더의 모든 데이터를 전송하여 대역폭을 낭비하고 있습니다.

서버라면 로컬 스토리지가 그다지 유용하지 않습니다. 데이터를 어떻게든(Ajax 또는 숨겨진 양식 필드 등을 사용하여) 전달해야 하기 때문입니다. 서버가 각 요청에 대한 전체 데이터의 작은 하위 집합만 필요로 하는 경우 괜찮을 수 있습니다.

어느 쪽이든 세션 쿠키를 쿠키로 남겨두고 싶을 것입니다.

기술적 차이 및 내 이해에 따라:

1. 쿠키는 데이터를 저장하는 오래된 방법과는 별도로 쿠키 당 4096 바이트(실제로는 4095바이트)의 제한을 제공합니다. 로컬 스토리지는 도메인당 최대 5MB입니다. 따라서 질문 에서도 언급합니다.

2. localStorage Storage 인터페이스의 구현입니다. 만료 날짜 없이 데이터를 저장하고 JavaScript를 통해서만 지워지거나 쿠키 만료와 달리 브라우저 캐시/로컬에 저장된 데이터를 지웁니다.

jpsimons

JWT와 관련하여 Stormpath 는 JWT를 저장하는 가능한 방법과 각 방법과 관련된 (비)장점을 설명하는 상당히 유용한 기사를 작성했습니다.

또한 XSS 및 CSRF 공격에 대한 간략한 개요와 이에 대처하는 방법도 있습니다.

기사가 오프라인으로 전환되거나 사이트가 다운되는 경우를 대비하여 아래 기사의 일부 짧은 스니펫을 첨부했습니다.

로컬 스토리지

문제:

웹 저장소(localStorage/sessionStorage)는 동일한 도메인에서 JavaScript를 통해 액세스할 수 있습니다. 즉, 사이트에서 실행되는 모든 JavaScript는 웹 저장소에 액세스할 수 있으며 이로 인해 XSS(교차 사이트 스크립팅) 공격에 취약할 수 있습니다. 간단히 말해서 XSS는 공격자가 페이지에서 실행될 JavaScript를 삽입할 수 있는 일종의 취약점입니다. 기본 XSS 공격은 공격자가 alert('You are Hacked'); 브라우저에서 실행되고 다른 사용자가 볼 수 있는지 확인하기 위해 양식으로 변환합니다.

방지:

XSS를 방지하기 위해 일반적인 응답은 신뢰할 수 없는 모든 데이터를 이스케이프하고 인코딩하는 것입니다. 그러나 이것은 전체 이야기와 거리가 멀다. 2015년에 최신 웹 앱은 CDN 또는 외부 인프라에서 호스팅되는 JavaScript를 사용합니다. 최신 웹 앱에는 A/B 테스트, 깔때기/시장 분석 및 광고를 위한 타사 JavaScript 라이브러리가 포함됩니다. 우리는 Bower와 같은 패키지 관리자를 사용하여 다른 사람의 코드를 우리 앱으로 가져옵니다.

사용하는 스크립트 중 하나만 손상된 경우에는 어떻게 됩니까? 악성 JavaScript가 페이지에 포함될 수 있으며 웹 저장소가 손상됩니다. 이러한 유형의 XSS 공격은 자신도 모르게 사이트를 방문하는 모든 사람의 웹 저장소를 얻을 수 있습니다. 이것이 아마도 많은 조직에서 웹 스토리지에 가치 있는 것을 저장하거나 정보를 신뢰하지 말라고 조언하는 이유일 것입니다. 여기에는 세션 식별자와 토큰이 포함됩니다.

웹 저장소는 저장 메커니즘으로서 전송 중에 보안 표준을 적용하지 않습니다. Web Storage를 읽고 사용하는 사람은 누구든지 HTTP가 아닌 HTTPS를 통해 JWT를 항상 보내도록 주의를 기울여야 합니다.

쿠키

문제:

HttpOnly 쿠키 플래그와 함께 사용되는 쿠키는 JavaScript를 통해 액세스할 수 없으며 XSS에 영향을 받지 않습니다. 보안 쿠키 플래그를 설정하여 쿠키가 HTTPS를 통해서만 전송되도록 할 수도 있습니다. 이것은 쿠키가 과거에 토큰이나 세션 데이터를 저장하는 데 활용되었던 주된 이유 중 하나입니다. 최신 개발자는 전통적으로 서버에 상태를 저장해야 했기 때문에 쿠키 사용을 주저하고 있으며, 따라서 RESTful 모범 사례를 위반합니다. 저장 메커니즘으로서의 쿠키는 JWT를 쿠키에 저장하는 경우 서버에 상태를 저장할 필요가 없습니다. 이는 JWT가 서버가 요청을 처리하는 데 필요한 모든 것을 캡슐화하기 때문입니다.

그러나 쿠키는 CSRF(교차 사이트 요청 위조)와 같은 다른 유형의 공격에 취약합니다. CSRF 공격은 악성 웹 사이트, 이메일 또는 블로그로 인해 사용자의 웹 브라우저가 사용자가 현재 인증된 신뢰할 수 있는 사이트에서 원치 않는 작업을 수행하도록 할 때 발생하는 공격 유형입니다. 이것은 브라우저가 쿠키를 처리하는 방법에 대한 악용입니다. 쿠키는 허용된 도메인에만 보낼 수 있습니다. 기본적으로 이것은 원래 쿠키를 설정한 도메인입니다. 귀하가 galaxies.com 또는 hahagonnahackyou.com에 있는지 여부에 관계없이 쿠키는 요청에 대해 전송됩니다.

방지:

최신 브라우저는 HttpOnly 및 Secure 외에 SameSite 플래그를 지원합니다. 이 플래그의 목적은 쿠키가 사이트 간 요청에서 전송되는 것을 방지하여 다양한 CSRF 공격을 방지하는 것입니다.

SameSite 지원하지 않는 브라우저의 경우 동기화된 토큰 패턴을 사용하여 CSRF를 방지할 수 있습니다. 이것은 복잡하게 들리지만 모든 최신 웹 프레임워크는 이를 지원합니다.

예를 들어, AngularJS에는 귀하의 도메인에서만 쿠키에 액세스할 수 있는지 확인하는 솔루션이 있습니다. AngularJS 문서에서 바로:

XHR 요청을 수행할 때 $http 서비스는 쿠키(기본적으로 XSRF-TOKEN)에서 토큰을 읽고 이를 HTTP 헤더(X-XSRF-TOKEN)로 설정합니다. 귀하의 도메인에서 실행되는 JavaScript만이 쿠키를 읽을 수 있으므로 귀하의 서버는 XHR이 귀하의 도메인에서 실행되는 JavaScript에서 온 것임을 확신할 수 있습니다. xsrfToken JWT 클레임을 포함하여 이 CSRF 보호를 상태 비저장으로 만들 수 있습니다.

 { "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "tom@andromeda.com", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }

웹 앱 프레임워크의 CSRF 보호를 활용하면 JWT를 저장하기 위한 쿠키가 견고해집니다. API에서 HTTP Referer 및 Origin 헤더를 확인하여 CSRF를 부분적으로 방지할 수도 있습니다. CSRF 공격에는 애플리케이션과 관련이 없는 Referer 및 Origin 헤더가 있습니다.

전체 기사는 https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ 에서 찾을 수 있습니다.

토큰 자체의 구조와 관련하여 JWT를 가장 잘 설계하고 구현하는 방법에 대한 유용한 기사도 있습니다. https://stormpath.com/blog/jwt-the-right-way/

XtraSimplicity

localStorage 를 사용하여 웹 애플리케이션은 사용자의 브라우저 내에서 로컬로 데이터를 저장할 수 있습니다. HTML5 이전에는 애플리케이션 데이터가 모든 서버 요청에 포함된 쿠키에 저장되어야 했습니다. 웹 사이트 성능에 영향을 주지 않고 많은 양의 데이터를 로컬에 저장할 수 있습니다. localStorage 가 더 현대적이지만 두 기술 모두 장단점이 있습니다.

쿠키

장점

• 레거시 지원(영원히 제공됨)
• 영구 데이터
• 만료 날짜
• 쿠키는 세션 동안 사용자 브라우저에 대한 XSS 공격을 제한할 수 있는 HTTPOnly로 표시될 수 있습니다(XSS 공격에 대한 완전한 면역성을 보장하지 않음).

단점

• 각 도메인은 모든 쿠키를 단일 문자열에 저장하므로 데이터 구문 분석이 어려울 수 있습니다.
• 데이터가 암호화되지 않아 문제가 됩니다... ... 크기는 작지만 모든 HTTP 요청과 함께 쿠키가 전송됩니다. 제한된 크기(4KB)

로컬 스토리지

장점

• 대부분의 최신 브라우저에서 지원
• 브라우저에 직접 저장되는 영구 데이터
• 동일 출처 규칙이 로컬 스토리지 데이터에 적용됨
• 모든 HTTP 요청과 함께 전송되지 않음
• 도메인당 ~5MB 저장용량(5120KB)

단점

• 이전에는 지원되지 않음: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• 서버에 저장된 클라이언트 정보가 필요한 경우 의도적으로 보내야 합니다.

localStorage 사용법은 세션과 거의 동일합니다. 그들은 거의 정확한 방법을 가지고 있으므로 세션에서 localStorage 전환하는 것은 정말 어린아이의 장난입니다. 그러나 저장된 데이터가 애플리케이션에 정말 중요한 경우 localStorage 를 사용할 수 없는 경우 쿠키를 백업으로 사용할 것입니다. localStorage 에 대한 브라우저 지원을 확인하려면 이 간단한 스크립트를 실행하기만 하면 됩니다.

 /* * function body that test if storage is available * returns true if localStorage is available and false if it's not */ function lsTest(){ var test = 'test'; try { localStorage.setItem(test, test); localStorage.removeItem(test); return true; } catch(e) { return false; } } /* * execute Test and run our custom script */ if(lsTest()) { // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar window.localStorage.setItem(name, 1); console.log('localStorage where used'); // log } else { document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC"; console.log('Cookie where used'); // log }

쿠키에 계속 액세스할 수 있는 'http'에서 'https' 보안 프로토콜로 전환하면 localStorage를 사용할 수 없다는 사실을 누군가가 알아차린 것처럼 "보안(SSL) 페이지의 localStorage 값이 격리됩니다." 이것은 보안 프로토콜로 작업하는 경우 알아야 할 중요합니다.

DevWL

쿠키 :

1. HTML5 이전에 도입되었습니다.
2. 유효기간이 있습니다.
3. JS 또는 브라우저의 Clear Browsing Data에 의해 또는 만료 날짜 이후에 삭제됩니다.
4. 각 요청마다 서버로 전송됩니다.
5. 용량은 4KB입니다.
6. 문자열만 쿠키에 저장할 수 있습니다.
7. 쿠키에는 영구 및 세션의 두 가지 유형이 있습니다.

로컬 스토리지:

1. HTML5와 함께 도입되었습니다.
2. 유효기간이 없습니다.
3. JS 또는 브라우저의 브라우징 데이터 지우기에 의해 지워집니다.
4. 데이터를 서버로 보내야 하는 시기를 선택할 수 있습니다.
5. 용량은 5MB입니다.
6. 데이터는 무기한 저장되며 문자열이어야 합니다.
7. 한 종류만 있습니다.

Seyedraouf Modarresi

사용자가 일부 모바일 Safari 버전에서 "비공개" 모드로 탐색할 때 localStorage 사용할 수 없다는 점도 언급할 가치가 있습니다.

MDN에서 인용( https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage ):

참고: iOS 5.1부터 Safari Mobile은 일반적으로 공간이 부족한 경우 OS의 요청에 따라 캐시 폴더에 localStorage 데이터를 저장합니다. Safari Mobile의 개인 정보 보호 브라우징 모드도 localStorage에 대한 쓰기를 완전히 방지합니다.

benjaminz

로컬 스토리지 속도는 클라이언트가 사용하는 브라우저와 운영 체제에 따라 크게 달라집니다. Mac의 Chrome 또는 Safari는 특히 최신 API를 사용하는 PC의 Firefox보다 훨씬 빠를 수 있습니다. 항상 그렇듯이 테스트는 친구입니다(벤치마크를 찾을 수 없었습니다).

쿠키와 로컬 스토리지에 큰 차이가 없습니다. 또한 호환성 문제에 대해 더 걱정해야 합니다. 모든 브라우저가 새로운 HTML5 API를 지원하기 시작한 것은 아니므로 쿠키가 속도와 호환성을 위한 최선의 선택이 될 것입니다.

pop850

로컬 저장소는 최대 5mb 오프라인 데이터를 저장할 수 있는 반면 세션은 최대 5mb 데이터를 저장할 수도 있습니다. 그러나 쿠키는 텍스트 형식으로 4kb 데이터만 저장할 수 있습니다.

JSON 형식의 LOCAL 및 세션 저장 데이터, 따라서 구문 분석이 쉽습니다. 그러나 쿠키 데이터는 문자열 형식입니다.

Avinash Malhotra

주요 차이점:

용량:

• 로컬 스토리지: 10MB
• 쿠키: 4kb

브라우저 지원:

• 로컬 저장소: HTML5
• 쿠키: HTML4, HTML5

저장 위치:

• 로컬 저장소: 브라우저 전용
• 쿠키: 브라우저 및 서버

요청과 함께 보내기:

• 로컬 스토리지: 예
• 쿠키: 아니요

액세스 위치:

• 로컬 저장소: 모든 창
• 쿠키: 모든 창.

만료일:

• 로컬 저장소: 자바스크립트가 완료될 때까지 만료되지 않습니다.
• 쿠키: 예, 만료일이 있습니다.

참고: 당신에게 맞는 것을 사용하십시오.

MuhammadAliDEV

출처 : http:www.stackoverflow.com/questions/3220660/local-storage-vs-cookies