로컬 스토리지와 쿠키

로컬 스토리지와 쿠키

모든 쿠키를 로컬 스토리지로 이동하여 웹 사이트의 로딩 시간을 줄이고 싶습니다. 왜냐하면 쿠키의 기능이 같기 때문입니다.cookie 기능을 대체하기 위해 로컬 스토리지를 사용하는 경우 명백한 호환성 문제를 제외하고 장단점(특히 퍼포먼스 측면)이 있습니까?

쿠키와 로컬 스토리지는 다른 용도로 사용됩니다.쿠키는 주로 서버 측 읽기용이며 로컬 스토리지는 클라이언트 측에서만 읽을 수 있습니다.따라서 이 데이터가 필요한 것은 클라이언트와 서버 중 어느 쪽일까요?

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

서버의 경우 데이터를 (Ajax 또는 숨겨진 양식 필드 등과 함께) 전송해야 하기 때문에 로컬 스토리지는 그다지 유용하지 않습니다.서버가 각 요청에 대해 총 데이터 중 작은 부분 집합만 필요로 하는 경우에는 이 작업이 가능합니다.

세션 쿠키를 쿠키로 남겨두는 것이 좋습니다.

기술적인 차이와 내가 이해하는 바에 따르면:

1. 오래된 데이터 저장 방법 외에 쿠키에서는 쿠키당 4096바이트(실제로 4095바이트)의 제한이 있습니다.로컬 스토리지는 도메인당 최대 10MB입니다.스택 오버플로우 질문에서도 언급하고 있습니다.

2. localStorage의 실장입니다.Storage인터페이스만료 날짜가 없는 데이터를 저장하고 쿠키 만료와 달리 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와 같은 패키지 매니저를 사용하여 다른 사람의 코드를 앱에 Import합니다.

사용하는 스크립트 중 하나만 손상된 경우에는 어떻게 해야 합니까?페이지에 악의적인 JavaScript가 포함되어 웹 스토리지가 손상될 수 있습니다.이러한 유형의 XSS 공격은 사용자 사이트를 방문하는 모든 사용자의 웹 스토리지를 자신도 모르게 손상시킬 수 있습니다.이러한 이유로 많은 조직이 웹 스토리지에 가치 있는 정보를 저장하거나 신뢰하지 않도록 권장하고 있습니다.여기에는 세션 ID 및 토큰이 포함됩니다.

스토리지 메커니즘으로서 Web Storage는 전송 중에 보안 표준을 적용하지 않습니다.Web Storage를 읽고 사용하는 사용자는 항상 HTTP를 사용하지 않고 HTTPS를 통해 JWT를 전송하기 위해 충분한 조사를 수행해야 합니다.

쿠키

문제:

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

단, cookie는 다른 유형의 공격에 취약합니다.크로스 사이트 요구 위조(CSRF)입니다.CSRF 공격은 악의적인 웹 사이트, 전자 메일 또는 블로그로 인해 사용자가 현재 인증되어 있는 신뢰할 수 있는 사이트에서 사용자의 웹 브라우저가 원치 않는 액션을 수행할 때 발생하는 공격 유형입니다.이는 브라우저가 쿠키를 처리하는 방식을 악용한 것입니다.cookie는 허용된 도메인에만 전송할 수 있습니다.기본적으로는 이 도메인은 cookie를 처음 설정한 도메인입니다.쿠키는 galaxies.com 또는 hahagonnahackyou.com 중 어느 쪽에 있든 요청을 위해 전송됩니다.

예방:

최신 브라우저는 플래그를 지원하며,HttpOnly ★★★★★★★★★★★★★★★★★」Secure이 플래그의 목적은 cookie가 사이트 간 요구로 전송되는 것을 방지하고 다양한 종류의 CSRF 공격을 방지하는 것입니다.

하지 SameSiteCSRF는 동기화된 토큰 패턴을 사용하여 방지할 수 있습니다.이것은 복잡하게 들리지만, 모든 최신 웹 프레임워크가 이를 지원합니다.

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

XHR "$http "cookie (XSRF-TOKEN)" "HTTP " " (X-XSRF-TOKEN)" "HTTP " (X-XSRF-TOKEN)" "HTTP " (X-XSRF-TOKEN)" 입니다.도메인에서 실행되는 JavaScript만 쿠키를 읽을 수 있으므로 XHR이 도메인에서 실행되는 JavaScript에서 가져온 것임을 서버에서 확인할 수 있습니다. CSRF , 「CSRF」를 합니다.xsrfTokenJWT jw jw :

{
  "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 공격에는 애플리케이션과 무관한 Referrer 헤더와 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 이전에는 모든 서버 요청에 포함된 쿠키에 애플리케이션 데이터를 저장해야 했습니다.웹 사이트의 성능에 영향을 주지 않고 대량의 데이터를 로컬로 저장할 수 있습니다.일일 ~일도 although although although although 。localStorage좀 더 현대적이고 두 기술 모두 장단점이 있습니다.

쿠키

장점

• 레거시 지원(영구적으로 사용 가능)
• 영속적인 데이터
• 유효기간
• 쿠키는 HTTPOnly로 마크되어 세션 중에 XSS atacks를 사용자 브라우저로 제한할 수 있습니다(XSS atacks에 대한 완전한 내성을 보장하지는 않습니다).

단점

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

로컬 스토리지

장점

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

단점

• IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0은 지원되지 않습니다.
• 서버에 저장되어 있는 클라이언트 정보가 필요한 경우는, 의도적으로 송신할 필요가 있습니다.

localStorage1번으로 하다은 거의 있기 에서 세션으로 합니다.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
}

"Secure(SSL) 페이지의 local Storage values is is olated" (로컬 스토리지 값은 격리되어 있습니다) 누군가 'http'에서 'https' 보안 프로토콜로 전환하면 localStorage를 사용할 수 없으며 쿠키가 계속 액세스할 수 있습니다.보안 프로토콜을 사용하는 경우 이 점에 유의해야 합니다.

쿠키:

1. HTML5보다 먼저 도입되었습니다.
2. 유효기간이 있습니다.
3. JS 또는 브라우저의 검색 데이터 지우기에 의해 또는 만료일 후에 지워집니다.
4. 각 요청별로 서버로 전송됩니다.
5. 용량은 4KB입니다.
6. 쿠키에는 문자열만 저장할 수 있습니다.
7. cookie에는 persistent와 session의 두 가지 유형이 있습니다.

로컬 스토리지:

1. HTML5에서 도입.
2. 유효기간이 없습니다.
3. JS 또는 브라우저의 Clear Browsing Data에 의해 지워졌습니다.
4. 데이터를 서버로 전송해야 하는 시기를 선택할 수 있습니다.
5. 용량은 5MB입니다.
6. 데이터는 무기한 저장되며 문자열이어야 합니다.
7. 타입은 1개뿐입니다.

주요 차이점:

용량:

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

브라우저 지원:

• 로컬 스토리지: HTML5
• 쿠키: HTML4, HTML5

보관 장소:

• 로컬 스토리지:브라우저만
• 쿠키:브라우저 및 서버

요청과 함께 보내기:

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

액세스원:

• 로컬 스토리지:임의의 창
• 쿠키:임의의 창

유효기간:

• 로컬 스토리지:Javascript가 완료될 때까지 만료되지 않습니다.
• 쿠키:네, 유효기간을 가지세요.

주의: 자신에게 맞는 것을 사용하십시오.

가 있다localStorage일부 버전의 모바일 Safari에서 사용자가 "개인" 모드로 브라우즈할 때는 사용할 수 없습니다.

2018년 WayBack Archive of MDN 토픽에서 인용:

주의: iOS 5.1 이후 Safari Mobile 스토어localStorage캐시 폴더 내의 데이터는 OS의 지시에 따라 정기적으로 정리됩니다(일반적으로 공간이 부족한 경우). Safari 모드에서는 Safari Mobile에 쓸 수.localStorage전적으로.

쿠키:

• 는 JavaScript에서 액세스할 수 있기 때문에 XSS 공격(사이트 간 스크립팅 공격)에 의해 Cookie의 데이터가 도용될 수 있습니다.단, HttpOnly 플래그를 Cookie로 설정하면 JavaScript에 의한 접근이 금지되므로 Cookie의 데이터는 XSS 공격으로부터 보호됩니다.

• 는 CSRF(Cross Site Request Formature)에 취약하지만 Lax에서 Cookie로 SameSite 플래그를 설정하면 CSRF가 경감되고 SameSite 플래그를 Strict에서 Cookie로 설정하면 CSRF가 방지됩니다.

• 유효기간이 경과하면 자동으로 쿠키가 삭제되기 때문에 쿠키 삭제를 잊어버린 경우에도 유효기간 때문에 자동으로 쿠키가 삭제됩니다.

• 는 일반적인 크기로서 약 4KB입니다(브라우저에 따라 다름).

로컬 스토리지:

• JavaScript에 의해 액세스 할 수 있기 때문에 로컬 스토리지의 데이터가 XSS 공격(사이트 간 스크립팅 공격)에 의해 도난당할 수 있습니다.또한 제가 조사한 바와 같이 로컬 스토리지의 XSS 공격에는 쉽게 막을 수 있는 방법이 없습니다.

• 는 CSRF(Cross Site Request Formature)에 취약하지 않습니다.

• 에는 만료일이 없으므로 로컬 저장소 데이터를 삭제하는 것을 잊은 경우 로컬 저장소 데이터가 영구히 남아 있을 수 있습니다.

• (브라우저에 따라 다름)의 일반적인 크기는 약 5MB입니다.

중요한 데이터에는 Cookie를 사용하고 중요하지 않은 데이터에는 Local Storage를 사용할 것을 권장합니다.

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

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

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

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

언급URL : https://stackoverflow.com/questions/3220660/local-storage-vs-cookies