Чи безпечно зберігати jwt в localStorage за допомогою reactjs?

Зараз я будую додаток на одній сторінці за допомогою reactjs. Я читав, що багато причин невикористання localStorage пов’язані з уразливістю XSS. Оскільки React уникає всіх даних користувачів, чи стало б безпечно використовувати localStorage?

У більшості сучасних додатків для однієї сторінки нам дійсно доводиться зберігати маркер десь на стороні клієнта (найпоширеніший випадок використання - щоб користувач увійшов у систему після оновлення сторінки).

Всього доступно 2 варіанти: Веб-зберігання (зберігання сеансу, локальне зберігання) та cookie на стороні клієнта. Обидва варіанти широко використовуються, але це не означає, що вони дуже безпечні.

Том Ебботт добре підсумовує сесію JWTСайми для зберігання та локальну безпеку :

Веб-сховище (localStorage / sessionStorage) доступне через JavaScript в одному домені. Це означає, що будь-який JavaScript, що працює на вашому веб-сайті, матиме доступ до веб-сховища, і через це може бути вразливим для атак міжсайтового скриптування (XSS) . У двох словах, XSS - це тип вразливості, коли зловмисник може вводити JavaScript, який працюватиме на вашій сторінці. Основні XSS-атаки намагаються ввести JavaScript через введення форми, де зловмисник вводить <script>alert('You are Hacked');</script>форму, щоб побачити, чи керує він браузером і чи можуть його переглядати інші користувачі.

Для запобігання XSS загальною відповіддю є уникнення та кодування всіх ненадійних даних. Реагуйте (в основному) це для вас! Ось чудова дискусія про те, наскільки захист уразливості XSS відповідає React .

Але це не охоплює всіх можливих уразливостей! Ще одна потенційна загроза - використання JavaScript, розміщеного на CDN або зовнішній інфраструктурі .

Ось знову Том:

Сучасні веб-програми включають сторонні бібліотеки JavaScript для тестування A / B, аналіз воронки / ринку та рекламу. Ми використовуємо менеджери пакетів, як Bower, для імпорту коду інших людей у ​​наші програми.

Що робити, якщо порушено лише один із сценаріїв, якими ви користуєтесь? Зловмисний JavaScript може бути вбудований на сторінку, а Веб-зберігання порушено. Ці типи XSS-атак можуть отримати веб-сховище кожного, хто відвідує ваш сайт, без їх відома. Ймовірно, тому група організацій радить не зберігати нічого корисного або довіряти будь-якій інформації у веб-сховищі. Сюди входять ідентифікатори і маркери сеансу.

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

Я знаю, що це давнє запитання, але згідно з тим, що сказав @ mikejones1477, сучасні бібліотеки та фреймворки уникають тексту, що забезпечує захист від XSS. Причиною, чому файли cookie не є безпечним методом використання облікових даних, полягає в тому, що файли cookie не перешкоджають CSRF, коли це місцевийStorage (також пам’ятайте, що файли cookie доступні і через javascript, тому XSS не є великою проблемою тут), ця відповідь відновиться, чому .

Причиною зберігання маркера аутентифікації у локальному сховищі та вручну додавати його до кожного запиту захищає від CSRF - це ключове слово: manual. Оскільки браузер не надсилає автоматично цей маркер, якщо я відвідаю evil.com і йому вдасться надіслати POST http://example.com/delete-my-account , він не зможе надіслати мій авторський маркер, так запит ігнорується.

Звичайно, httpOnly - це святий грааль, але ви не можете отримати доступ з reakctjs або будь-якої js-фрейму, поруч із вами ще є вразливість CSRF. Моєю рекомендацією буде локальне зберігання, або якщо ви хочете використовувати файли cookie, переконайтеся, що реалізуєте якесь рішення вашої проблеми з CSRF, як, наприклад, django .

Що стосується CDN, переконайтеся, що ви не використовуєте якогось дивного CDN, наприклад, CDN, такого як Google або Bootstrap, підтримуються спільнотою і не містять зловмисного коду, якщо ви не впевнені, ви можете оглянути.

В основному це нормально, щоб зберігати свій JWT у вашому локальному сховищі.

І я думаю, що це хороший шлях. Якщо ми говоримо про XSS, XSS з використанням CDN, це також потенційний ризик отримати вхід / пропуск вашого клієнта. Збереження даних у локальному сховищі запобіжить атакам CSRF принаймні.

Вам потрібно бути обізнаним про обидва і вибирати те, що ви хочете. Обидві атаки - це не все, що вам потрібно знати, просто пам’ятайте: ВСЕ ПРИЛОЖЕННЯ ТОЛЬКО ТАКЕ БЕЗПЕЧНО, НАКІЛЬШЕ ЗАБЕЗПЕЧЕННЯ ВАШОГО ПРИЛОЖЕННЯ.

Знову зберігання в порядку, будьте вразливі до XSS, CSRF, ... ні

Небезпечно, якщо ви використовуєте CDN:

Зловмисний JavaScript може бути вбудований на сторінку, а Веб-зберігання порушено. Ці типи XSS-атак можуть отримати веб-сховище кожного, хто відвідує ваш сайт, без їх відома. Ймовірно, тому група організацій радить не зберігати нічого корисного або довіряти будь-якій інформації у веб-сховищі. Сюди входять ідентифікатори і маркери сеансу.

через шторм

Будь-який сценарій, який ви потребуєте ззовні, може бути скомпрометований і може захопити будь-який JWTS зі сховища вашого клієнта і відправити особисті дані назад на сервер зловмисника.

Localstorage розроблений так, щоб бути доступним через javascript, тому він не забезпечує захисту XSS. Як згадується в інших відповідях, існує купа можливих способів зробити XSS-атаку, від якої локальне зберігання за замовчуванням не захищене.

Однак у файлах cookie є прапори безпеки, які захищають від атак XSS та CSRF. Прапор HttpOnly запобігає доступу JavaScript до клієнтського файлу cookie, захищений прапор дозволяє лише браузеру переносити файл cookie через ssl, а прапор SameSite гарантує, що файл cookie буде надісланий лише до походження. Хоча я щойно перевірив, і SameSite зараз підтримується лише в Opera та Chrome, тому для захисту від CSRF краще використовувати інші стратегії. Наприклад, надсилання зашифрованого маркера в інший файл cookie з деякими загальнодоступними даними користувачів.

Тож файли cookie є більш безпечним вибором для зберігання даних аутентифікації.

Спосіб для цього - це врахувати рівень ризику чи шкоди.

Ви створюєте додаток без користувачів, POC / MVP? Ви стартап, якому потрібно швидко вийти на ринок та протестувати ваш додаток? Якщо так, я б, напевно, просто реалізував найпростіше рішення та зосередився на пошуку придатності товару до ринку. Використовуйте localStorage, як його часто простіше у виконанні.

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

Використання локального зберігання та зберігання файлів cookie / сеансів має свої плюси і мінуси.

Як зазначено в першій відповіді: Якщо у вашої програми є вразливість XSS, це не захистить вашого користувача. Оскільки більшість сучасних додатків мають десяток і більше різних залежностей, стає важче гарантувати, що одна із залежностей вашої програми не є вразливою до XSS.

Якщо у вашої програми є вразливість XSS і хакер зміг її використати, хакер зможе виконувати дії від імені вашого користувача. Хакер може виконувати запити GET / POST, вилучаючи маркер з localStorage або виконувати запити POST, якщо маркер зберігається у файлі cookie, що містить лише http.

Єдина нижня сторона зберігання вашого маркера в локальному сховищі - це хакер зможе прочитати ваш маркер.

Чи не прийнятні ні файли cookie localStorage, ні httpOnly? Що стосується компрометованої третьої сторони бібліотеки, єдине мені відоме рішення, яке зменшить / запобіжить крадіжці конфіденційної інформації, буде примусовою цінністю субресурсів .

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

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

Файл cookie httpOnly не перешкоджатиме доступу з іншого комп'ютера, але нічого не зробить, щоб хакер не маніпулював комп'ютером користувача.

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

    import SimpleCrypto from 'simple-crypto-js';

    const saveToken = (token = '') => {
          const encryptInit = new SimpleCrypto('PRIVATE_KEY_STORED_IN_ENV_FILE');
          const encryptedToken = encryptInit.encrypt(token);

          localStorage.setItem('token', encryptedToken);
     }

Потім, перш ніж використовувати ваш маркер, розшифруйте його за допомогою PRIVATE_KEY_STORED_IN_ENV_FILE