로컬 저장소와 쿠키

로컬 저장소와 쿠키

---

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

---

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

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

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

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

기술적 차이와 나의 이해에 따라 :

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

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

---

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

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

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

로컬 스토리지

문제점 :

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

예방:

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

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

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

쿠키

문제점 :

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

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

예방:

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더 현대적 이지만 두 기술에는 장단점이 있습니다.

쿠키

장점

• 레거시 지원 (영원히 존재)
• 영구 데이터
• 만료일

단점

• Each domain stores all its cookies in a single string, which can make parsing data difficult
• Data is unencrypted, which becomes an issue because... ... though small in size, cookies are sent with every HTTP request Limited size (4KB)
• SQL injection can be performed from a cookie

Local storage

Pros

• Support by most modern browsers
• Persistent data that is stored directly in the browser
• Same-origin rules apply to local storage data
• Is not sent with every HTTP request
• ~5MB storage per domain (that's 5120KB)

Cons

• Not supported by anything before: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• If the server needs stored client information you purposely have to send it.

localStorage usage is almost identical with the session one. They have pretty much exact methods, so switching from session to localStorage is really child's play. However, if stored data is really crucial for your application, you will probably use cookies as a backup in case localStorage is not available. If you want to check browser support for localStorage, all you have to do is run this simple script:

/* 
* 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
}

"localStorage values on Secure (SSL) pages are isolated" as someone noticed keep in mind that localStorage will not be available if you switch from 'http' to 'https' secured protocol, where the cookie will still be accesible. This is kind of important to be aware of if you work with secure protocols.

---

Well, local storage speed greatly depends on the browser the client is using, as well as the operating system. Chrome or Safari on a mac could be much faster than Firefox on a PC, especially with newer APIs. As always though, testing is your friend (I could not find any benchmarks).

I really don't see a huge difference in cookie vs local storage. Also, you should be more worried about compatibility issues: not all browsers have even begun to support the new HTML5 APIs, so cookies would be your best bet for speed and compatibility.

---

It is also worth mentioning that localStorage cannot be used when users browse in "private" mode in some versions of mobile Safari.

Quoted from MDN (https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage):

Note: Starting with iOS 5.1, Safari Mobile stores localStorage data in the cache folder, which is subject to occasional clean up, at the behest of the OS, typically if space is short. Safari Mobile's Private Browsing mode also prevents writing to localStorage entirely.

---

Local storage can store up to 5mb offline data, whereas session can also store up to 5 mb data. But cookies can store only 4kb data in text format.

LOCAl and Session storage data in JSON format, thus easy to parse. But cookies data is in string format.

참고URL : https://stackoverflow.com/questions/3220660/local-storage-vs-cookies