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

Question

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

Answer 1

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

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

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

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

В соответствии с техническим отличием, а также моим пониманием:

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

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

Answer 2

В контексте JWT Stormpath написал довольно полезную статью, в которой изложены возможные способы их хранения и (не) преимущества, относящиеся к каждому методу.

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

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

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

Проблемы:

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

Предупреждение:

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

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

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

печенье

Проблемы:

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

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

Предупреждение:

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

Например, AngularJS имеет решение для проверки того, что cookie доступно только вашему домену. Прямо из документов AngularJS:

При выполнении запросов XHR служба $ http считывает токен из cookie (по умолчанию XSRF-TOKEN) и устанавливает его как заголовок HTTP (Х-XSRF-ЗНАК). Поскольку только JavaScript, который работает на вашем домене, может прочитайте куки, ваш сервер может быть уверен, что 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-защиты вашего веб-фреймворка делает файлы cookie потрясающими Твердое вещество для хранения JWT. CSRF также может быть частично предотвращен проверка HTTP Referer и заголовка Origin из вашего API. 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/

Answer 3

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

Печенье

Плюсы

• Устаревшая поддержка (она была всегда)
• Постоянные данные
• Срок годности

Против

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

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

Плюсы

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

Против

• До этого ничего не поддерживалось: 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
}

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

Answer 4

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

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

)

Примечание. Начиная с iOS 5.1, Safari Mobile сохраняет данные localStorage в папка кеша, которая может время от времени очищаться Приказ ОС, как правило, если места мало. Частный Safari Mobile Режим просмотра также полностью запрещает запись в localStorage.

Answer 5

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

Данные LOCAl и Session storage в формате JSON, что позволяет легко их анализировать.Но данные куки-файлов представлены в строковом формате.

Answer 6

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

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