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

쿠키와 로컬 저장소는 다른 목적으로 사용됩니다. 쿠키는 주로 서버 측 을 읽기위한 것이며 로컬 저장소는 클라이언트 측 에서만 읽을 수 있습니다 . 따라서 문제는 앱에서 누가이 데이터 (클라이언트 또는 서버)가 필요한가?

클라이언트 (자바 스크립트) 인 경우 반드시 전환하십시오. 각 HTTP 헤더의 모든 데이터를 보내 대역폭을 낭비하고 있습니다.

서버 인 경우 로컬 스토리지는 Ajax 또는 숨겨진 양식 필드 등으로 데이터를 전달해야하므로 유용하지 않습니다. 서버가 각 요청에 대한 총 데이터의 작은 하위 집합 만 필요한 경우에는 괜찮을 수 있습니다.

그래도 세션 쿠키를 쿠키로 남겨두고 싶을 것입니다.

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

1. 쿠키는 오래된 데이터 저장 방법 외에도 쿠키 당 4096 바이트 (실제 4095) 의 제한을 제공합니다 . 로컬 저장소는 큰 같습니다 도메인 당 5메가바이트 - SO 질문 또한 그것을 언급하고있다.

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

JWT의 맥락에서 Stormpath 는 JWT를 저장하는 가능한 방법과 각 방법과 관련된 (단점)을 간략히 설명하는 상당히 유용한 기사를 작성했습니다.

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

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

로컬 스토리지

문제 :

웹 스토리지 (localStorage / sessionStorage)는 동일한 도메인에서 JavaScript를 통해 액세스 할 수 있습니다. 즉, 사이트에서 실행되는 모든 JavaScript는 웹 저장소에 액세스 할 수 있으며 이로 인해 사이트 간 스크립팅 (XSS) 공격에 취약 할 수 있습니다. 간단히 말해서 XSS는 공격자가 페이지에서 실행될 JavaScript를 주입 할 수있는 취약점 유형입니다. 기본 XSS 공격은 양식 입력을 통해 JavaScript를 주입하려고 시도합니다. 여기서 공격자는 경보를 보냅니다 ( 'You are Hacked'). 브라우저에서 실행되고 다른 사용자가 볼 수 있는지 양식으로

예방:

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

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

스토리지 메커니즘으로서 Web Storage는 전송 중에 보안 표준을 시행하지 않습니다. Web Storage를 읽고 사용하는 사람은 항상 HTTP를 통해 HTTPS를 통해 JWT를 보내지 않도록 실사를 수행해야합니다.

쿠키

문제 :

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

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

예방:

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

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

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

XHR 요청을 수행 할 때 $ http 서비스는 쿠키 (기본적으로 XSRF-TOKEN)에서 토큰을 읽고이를 HTTP 헤더 (X-XSRF-TOKEN)로 설정합니다. 도메인에서 실행되는 JavaScript 만 쿠키를 읽을 수 있으므로 서버는 XHR이 도메인에서 실행되는 JavaScript에서 온 것임을 확신 할 수 있습니다. xsrfTokenJWT 클레임 을 포함하여이 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/

을 사용 localStorage하면 웹 응용 프로그램이 사용자 브라우저 내에 로컬로 데이터를 저장할 수 있습니다. HTML5 이전에는 모든 서버 요청에 포함 된 응용 프로그램 데이터를 쿠키에 저장해야했습니다. 웹 사이트 성능에 영향을주지 않고 대량의 데이터를 로컬에 저장할 수 있습니다. localStorage더 현대적 이지만 두 기술에 대한 장단점이 있습니다.

쿠키

찬성

• 레거시 지원 (영원히있었습니다)
• 영구 데이터
• 만료 날짜

단점

• 각 도메인은 모든 쿠키를 단일 문자열로 저장하므로 구문 분석 데이터를 어렵게 만들 수 있습니다
• 크기는 작지만 쿠키는 모든 HTTP 요청마다 전송됩니다. 크기는 4KB입니다.
• 쿠키에서 SQL 삽입을 수행 할 수 있습니다

로컬 스토리지

찬성

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

단점

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

localStorage사용법은 세션 1과 거의 동일합니다. 그들은 거의 정확한 방법을 가지고 있으므로 세션에서 전환하는 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 값이 분리 됩니다." 보안 프로토콜로 작업하는 경우이 점을 알고 있어야합니다.

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

쿠키와 로컬 스토리지에는 큰 차이가 없습니다. 또한 호환성 문제에 대해 더 걱정해야합니다. 모든 브라우저가 새로운 HTML5 API를 지원하기 시작한 것은 아니기 때문에 쿠키는 속도와 호환성에 가장 적합한 방법입니다.

또한 언급 할만큼 가치입니다 localStorage사용자가 모바일 사파리의 일부 버전에서 "개인"모드에서 탐색 할 때 사용할 수 없습니다.

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

참고 : iOS 5.1부터 Safari Mobile은 로컬 스토리지 데이터를 캐시 폴더에 저장합니다. 캐시 폴더는 공간이 부족한 경우 OS의 요청에 따라 때때로 정리 될 수 있습니다. Safari Mobile의 개인 정보 보호 브라우징 모드는 localStorage에 대한 쓰기를 완전히 방지합니다.

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

JSON 형식의 LOCAl 및 세션 스토리지 데이터이므로 구문 분석이 쉽습니다. 그러나 쿠키 데이터는 문자열 형식입니다.

쿠키 :

1. HTML5 이전에 소개되었습니다.
2. 만료 날짜가 있습니다.
3. JS 또는 브라우저의 브라우징 데이터 지우기 또는 만료 날짜 후에 지 웁니다.
4. 각 요청마다 서버로 전송됩니다.
5. 용량은 4KB입니다.
6. 문자열에만 쿠키에 저장할 수 있습니다.
7. 영구 쿠키와 세션이라는 두 가지 쿠키 유형이 있습니다.

로컬 스토리지 :

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