Локальное хранилище против файлов cookie

Question

Я хочу уменьшить время загрузки на своих сайтах, перемещая все файлы cookie в локальное хранилище, поскольку они, похоже, имеют одинаковую функциональность. Существуют ли какие-либо плюсы/минусы (особенно с точки зрения производительности) в использовании локального хранилища для замены функций cookie, за исключением очевидных проблем с совместимостью?

Answer 1

Печенье и местное хранилище служат для разных целей. Файлы cookie в основном предназначены для чтения на стороне сервера, локальное хранилище может быть прочитано только на стороне клиента . Итак, вопрос в вашем приложении, кому эти данные нужны — клиенту или серверу?

Если это ваш клиент (ваш JavaScript), то обязательно переключитесь. Вы теряете пропускную способность, отправляя все данные в каждый HTTP-заголовок.

Если это ваш сервер, локальное хранилище не так полезно, потому что вам придется пересылать данные как-то (с полями Ajax или скрытой формы или что-то в этом роде). Это может быть хорошо, если серверу требуется только небольшое подмножество данных для каждого запроса.

В любом случае вы захотите оставить cookie сеанса как файл cookie.

В соответствии с технической разницы, а также мое понимание:

1. Помимо того, что старый способ сохранения данных, Cookies дают вам лимит байт (4095, на самом деле) - его на печенье. Локальное хранилище является столь же большой как 5МБ на домен - SO Question также упоминает, что

2. localStorage является реализация Storage интерфейса. Он хранит данные с без истечения срока действия и получает очищенную только через с помощью JavaScript или очистку кэша браузера/локально хранимых данных - в отличие от срока действия файла cookie.

Answer 2

Ну, локальная скорость хранения зависит от браузера, который использует клиент, а также от операционной системы. Chrome или Safari на Mac может быть намного быстрее, чем Firefox на ПК, особенно с новыми API. Как всегда, тестирование - ваш друг (я не мог найти никаких тестов).

Я действительно не вижу огромной разницы в cookie и локальном хранилище. Кроме того, вы должны больше беспокоиться о проблемах совместимости: не все браузеры даже начали поддерживать новые API-интерфейсы HTML5, поэтому файлы cookie будут наилучшим выбором для скорости и совместимости.

Answer 3

С localStorage веб-приложения могут хранить данные локально в браузере пользователя. До HTML5 данные приложения должны храниться в файлах cookie, включенных в каждый запрос сервера. localStorage более безопасен, и большие объемы данных могут храниться локально, не влияя на производительность веб-сайта. Хотя localStorage более современен, есть некоторые плюсы и минусы для обеих техник.

Печенье

Pros

• поддержка Наследство (это было вокруг навсегда)
• Стойкие данные
• Истечение даты

Cons

• Каждый домен хранит все свои куки в одну строку, которая может сделать синтаксического анализа данных трудно
• данных в незашифрованном виде, который становится проблемой, потому что ... ... хотя небольшие по размеру, печенье отправляются с каждым HTTP запрос Ограниченный размер (4KB)
• инъекции SQL может быть выполнена из печенья

местного хранения

Pros

• Поддержка большинства современных браузеров
• Стойкие данные, которые хранятся непосредственно в браузере
• правила общего происхождения относятся к локальным данным хранения
• не передается с каждым запросом HTTP
• ~ 5 МБ для хранения в домен (это 5120KB)

Против

• Не поддерживается ничем раньше: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• Если серверу необходимо хранить информацию о клиенте, у вас есть , чтобы отправить его.

localStorage Использование почти идентично сеансу. У них довольно точные методы, поэтому переход с сеанса на localStorage - это действительно детская игра. Однако, если сохраненные данные действительно важны для вашего приложения, вы, вероятно, будете использовать файлы cookie в качестве резервной копии в случае, если 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 
} 

«значения LocalStorage на Secure (SSL) страниц изолированы» , как кто-то заметил, держать в помните, что localStorage не будет доступен , если вы перейдете с защищенного протокола «http» на «https», где cookie по-прежнему будет доступен. Это важно для знать, если вы работаете с защищенными протоколами.

Answer 4

В контексте JWTs, Stormpath написал довольно полезную статью с изложением возможных способов их хранения, и (ОТСОЕДИНЯТЬ) преимущества, относящиеся к каждому методу.

Он также имеет краткий обзор атак XSS и CSRF и как вы можете сражаться с ними.

Я приложил несколько коротких отрывков из приведенной ниже статьи, в случае, если их статья отключена/их сайт идет вниз.

Локальное хранилище

Проблемы:

Web Storage (LocalStorage/sessionStorage) доступен через JavaScript на том же домене. Это означает, что любой JavaScript, работающий на вашем сайте, будет иметь доступ к веб-хранилищу, и из-за этого он может быть уязвим для атак на межсайтовый скриптинг (XSS). XSS в двух словах является типом уязвимости, когда злоумышленник может добавить JavaScript, который будет запущен на вашей странице. Базовые атаки XSS пытаются внедрить JavaScript через входы форм, где злоумышленник ставит предупреждение («Вы взломали»); в форму, чтобы увидеть, запущен ли он браузером и может быть просмотрен другими пользователями.

Профилактика:

Для предотвращения XSS, общий ответ, чтобы избежать и кодировать все ненадежные данные. Но это далеко не полная история. В 2015 году современные веб-приложения используют JavaScript, размещенный на CDN или вне инфраструктуры. Современные веб-приложения включают сторонние библиотеки JavaScript для тестирования A/B, анализа воронки/рынка и рекламы. Мы используем менеджеров пакетов, таких как Bower, для импорта кода других людей в наши приложения.

Что делать, если только один из скриптов, которые вы используете, скомпрометирован? Вредоносный JavaScript может быть встроен на страницу, а веб-хранилище - скомпрометировано. Эти типы атак XSS могут получить все веб-хранилище , которое посещает ваш сайт без их ведома. Вероятно, поэтому группа организаций рекомендует не хранить ничего ценного или доверять любой информации в веб-хранилище. Сюда входят идентификаторы сеанса и токены .

В качестве механизма хранения Web Storage не применяет безопасные стандарты во время передачи. Тот, кто читает Web Storage и использует его, должен выполнить свою должную осмотрительность, чтобы гарантировать, что они всегда отправляют JWT через HTTPS и никогда не будут HTTP.

Печенье

Проблемы:

Печенье, при использовании с HttpOnly флагом печенья, не доступны через JavaScript, и имеют иммунитет к XSS. Вы также можете установить флаг Secure cookie, чтобы гарантировать, что cookie отправляется только через HTTPS. Это одна из основных причин, по которой куки были использованы в прошлом для хранения токенов или данных сеанса. Современные разработчики не решаются использовать файлы cookie, поскольку они традиционно требуют сохранения состояния на сервере, тем самым нарушая лучшие практики RESTful.Куки-файлы в качестве механизма хранения не требуют сохранения состояния на сервере, если вы храните JWT в файле cookie. Это связано с тем, что JWT инкапсулирует все, что сервер должен обслуживать.

Тем не менее, файлы cookie уязвимы для различного типа атак: подделка запросов на межсайтовый запрос (CSRF). Атака CSRF - это тип атаки , который возникает, когда вредоносный веб-сайт, электронная почта или блог заставляет веб-браузер пользователя выполнять нежелательное действие на доверенном сайте, на котором пользователь в настоящее время проходит проверку подлинности. Это пример того, как браузер обрабатывает файлы cookie. Куки-файлы можно отправлять только в домены в , которые разрешены. По умолчанию это домен, изначально установить cookie. Куки будут отправляться на запрос независимо от , находитесь ли вы на galaxies.com или hahagonnahackyou.com.

Профилактика:

CSRF можно предотвратить с помощью синхронизированных моделей маркеров. Это звучит сложно, но все современные веб-фреймы имеют поддержку для .

Например, у AngularJS есть решение, подтверждающее, что cookie - это , доступный только вашему домену. Прямо из AngularJS Документов

При выполнении запросов XHR, служба $ HTTP считывает маркер из печенья (по умолчанию, XSRF-токен) и устанавливает его в качестве HTTP-заголовка (X-XSRF-токен). Поскольку только JavaScript, который работает в вашем домене, может читать cookie, ваш сервер может быть уверен, что XHR пришел с JavaScript, работающий в вашем домене. Вы можете сделать эту защиту CSRF без гражданства, включив требование xsrfToken JWT:

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

Использования защиты от CSRF своего приложения структуры веб делает печенье рок твердые для хранения JWT. CSRF также может быть частично предотвращен проверкой заголовка HTTP Referer и Origin вашего API. Атаки CSRF будут иметь заголовки Referer и Origin, которые не связаны с вашим запросом .

Полный текст статьи можно найти здесь: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Они также полезные статьи о том, как лучший дизайн и реализовать JWTs, в отношении структуры самого маркера: https://stormpath.com/blog/jwt-the-right-way/

Answer 5

Локальное хранилище может хранить до 10 Мб автономных данных, тогда как сеанс может хранить до 5 мб данных. Но файлы cookie могут хранить только 4 КБ данных в текстовом формате.

Answer 6

Также стоит упомянуть, что localStorage не может использоваться, когда пользователи просматривают «частный» режим в некоторых версиях мобильных Safari.

Цитируется MDN (https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage):

Примечание: Начиная с прошивкой 5.1, Safari Mobile хранит данные локального хранилища в папке с кешем, которая периодически подвергается очистке, на уровне , если это место является коротким. Safari Mobile's Private Режим просмотра также полностью запрещает запись на localStorage.