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

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

Якщо це ваш клієнт (ваш JavaScript), то будь-яким чином перемикайтесь. Ви витрачаєте пропускну здатність, надсилаючи всі дані у кожному заголовку HTTP.

Якщо це ваш сервер, локальне зберігання не настільки корисне, тому що вам доведеться якимось чином пересилати дані (разом з Ajax або прихованими полями форми або чим-небудь). Це може бути добре, якщо серверу потрібен лише невеликий підмножина загальної кількості даних для кожного запиту.

Хоча ви хочете залишити ваш сеансовий файл cookie як файл cookie будь-яким способом.

Відповідно до технічної різниці, а також мого розуміння:

1. Окрім того, що це старий спосіб збереження даних, Cookies надають вам обмеження в 4096 байт (фактично 4095) - це на печиво. Локальне сховище досягає 5 Мб на домен - ТАК Питання також згадує про це.

2. localStorageє реалізацією StorageІнтерфейсу. Він зберігає дані без закінчення терміну придатності та видаляється лише через JavaScript або очищення кешу браузера / даних, які зберігаються локально - на відміну від терміну дії файлів cookie.

У контексті СЗТ 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 раніше використовувались для зберігання жетонів або даних сеансу. Сучасні розробники не вагаються використовувати файли cookie, оскільки вони традиційно вимагають збереження стану на сервері, тим самим порушуючи RESTful кращі практики. Файли cookie як механізм зберігання не вимагають збереження стану на сервері, якщо ви зберігаєте JWT у файлі cookie. Це тому, що JWT інкапсулює все, що потрібно для обслуговування сервера.

Однак файли cookie вразливі до атак різного типу: підробка між запитами на веб-сайті (CSRF). Напад CSRF - це тип атаки, який виникає, коли шкідливий веб-сайт, електронна пошта чи блог змушує веб-браузер користувача здійснити небажану дію на надійному веб-сайті, на якому користувач наразі має автентифікацію. Це експлуатація того, як браузер обробляє файли cookie. Файл cookie може бути надісланий лише тим доменам, у яких це дозволено. За замовчуванням це домен, на який початково встановлено файл cookie. Файл cookie буде надісланий для запиту незалежно від того, перебуваєте ви на galaxies.com чи hahagonnahackyou.com.

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

Сучасні браузери підтримують SameSiteпрапор на додаток до HttpOnlyтаSecure . Мета цього прапора - запобігти передачі файлів cookie у запитах між веб-сайтами, запобігаючи багатьом видам атаки CSRF.

Для веб-переглядачів, які не підтримують SameSite, CSRF можна запобігти за допомогою синхронізованих шаблонів жетонів. Це звучить складно, але всі сучасні веб-рамки підтримують це.

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

Під час виконання запитів XHR служба $ http зчитує маркер із файлу cookie (за замовчуванням XSRF-TOKEN) і встановлює його як заголовка HTTP (X-XSRF-TOKEN). Оскільки тільки 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 рамки веб-додатків, файли 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/

З localStorageвеб - додатки можуть зберігати дані локально в браузері користувача. Перед HTML5 дані програми повинні були зберігатися у файлах cookie, включених до кожного запиту сервера. Велика кількість даних може зберігатися локально, не впливаючи на ефективність веб-сайту. ХочаlocalStorage це і сучасніше, є і деякі плюси і мінуси в обох методах.

Печиво

Плюси

• Підтримка спадщини (вона існувала назавжди)
• Постійні дані
• Терміни придатності

Мінуси

• Кожен домен зберігає всі файли cookie в одній рядку, що може ускладнити аналіз даних
• Дані не шифруються, що стає проблемою, оскільки ... ... хоча і невеликого розміру, файли cookie надсилаються з кожним запитом HTTP Обмежений розмір (4 КБ)
• Інжекція 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справді є дитячою грою. Однак якщо збережені дані дійсно важливі для вашої програми, ви, ймовірно, будете використовувати файли 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 на захищених (SSL) сторінках є ізольованими", оскільки хтось помітив, майте на увазі, що localStorage не буде доступний, якщо ви перейдете з "http" на захищений протокол "https", де файл cookie все ще буде доступний. Це важливо пам’ятати, якщо ви працюєте із захищеними протоколами.

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

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

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

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

Примітка. Починаючи з iOS 5.1, Safari Mobile зберігає дані localStorage у папці кешу, яка підлягає періодичному очищенню, за бажанням ОС, як правило, якщо місця не вистачає. Режим приватного перегляду Safari Mobile також не дозволяє повністю писати в localStorage.

Локальне сховище може зберігати до 5 Мб офлайн-даних, тоді як сеанс також може зберігати до 5 Мб даних. Але кукі-файли можуть зберігати лише 4 кб дані в текстовому форматі.

Дані зберігання LOCAl та Session у форматі JSON, таким чином, легко проаналізувати. Але дані cookie є у рядковому форматі.

Файли cookie :

1. Представлено до HTML5.
2. Має термін придатності.
3. Очистити JS або Очистити дані веб-переглядача або після закінчення терміну придатності.
4. Надсилатиметься на сервер за кожним запитом.
5. Ємність - 4 КБ.
6. Лише рядки можуть зберігати у файлах cookie.
7. Існує два типи cookie: стійкі та сесійні.

Місцеве зберігання:

1. Представлено HTML5.
2. Не має терміну придатності.
3. Очистити JS або Очистити дані веб-переглядача.
4. Ви можете вибрати, коли дані повинні бути надіслані серверу.
5. Ємність 5 Мб.
6. Дані зберігаються нескінченно і повинні бути рядковими.
7. Тільки одного типу.