Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Проблемы:

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

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

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

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

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

Cookies

Проблемы:

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

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

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

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

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

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

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "[email protected]",
  "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/

Ответ 3

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

Печенье

Pros

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

Cons

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

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

Pros

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

Cons

• Раньше ничего не поддерживали: 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 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", где файл cookie все еще будет доступен. Это очень важно знать, если вы работаете с защищенными протоколами.

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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