Безопасно ли хранить jwt в localStorage с помощью реакции?

Ответ 1

В большинстве современных одностраничных приложений нам действительно нужно хранить токен где-то на стороне клиента (наиболее распространенный вариант использования - чтобы пользователь вошел в систему после обновления страницы).

Доступно всего 2 варианта: веб-хранилище (хранилище сеансов, локальное хранилище) и файл cookie на стороне клиента. Оба варианта широко используются, но это не значит, что они очень безопасны.

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

Чтобы предотвратить XSS, общий ответ заключается в том, чтобы убежать и закодировать все ненадежные данные. Реакция (в основном) делает это для вас! Здесь большое обсуждение о том, насколько защита XSS-уязвимости отвечает за.

Но это не распространяется на все возможные уязвимости! Другой потенциальной угрозой является использование JavaScript, размещенного на CDN или внешней инфраструктуре.

Здесь снова Том:

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

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

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

Ответ 2

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

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

Конечно, httpOnly - это святой Грааль, но вы не можете получить доступ через responsejs или какую-либо инфраструктуру js, у вас все еще есть уязвимость CSRF. Я бы порекомендовал localalstorage или, если вы хотите использовать куки, убедитесь, что вы реализуете какое-то решение вашей проблемы CSRF, как это делает django.

Что касается CDN, убедитесь, что вы не используете какие-то странные CDN, например, CDN, такие как google или bootstrap, поддерживаются сообществом и не содержат вредоносного кода. Если вы не уверены, вы можете свободно просматривать.

Ответ 3

Это не безопасно, если вы используете CDN:

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

через шторм

Любой сценарий, который вам требуется извне, потенциально может быть скомпрометирован и может захватить любую JWTS из хранилища вашего клиента и отправить личные данные обратно на сервер злоумышленника.

Ответ 4

Localstorage предназначен для доступа к javascript, поэтому он не предоставляет никакой защиты XSS. Как упоминалось в других ответах, существует множество возможных способов атаки XSS, из которых localstorage не защищен по умолчанию.

Однако файлы cookie имеют флаги безопасности, которые защищают от атак XSS и CSRF. Флаг HttpOnly препятствует доступу javascript на стороне клиента к файлу cookie, флаг Secure позволяет браузеру передавать cookie через ssl, а флаг SameSite гарантирует, что cookie отправляется только в начало. Хотя я только что проверил и SameSite в настоящее время поддерживается только в Opera и Chrome, поэтому для защиты от CSRF лучше использовать другие стратегии. Например, отправка зашифрованного токена в другой файл cookie с некоторыми общедоступными пользовательскими данными.

Таким образом, файлы cookie являются более безопасным выбором для хранения данных аутентификации.

Ответ 5

В основном это нормально, чтобы сохранить JWT в локальном хранилище.

И я думаю, что это хороший путь. Если мы говорим о XSS, XSS с использованием CDN, это также потенциальный риск получения вашего входа в систему. Хранение данных в локальном хранилище будет предотвращать как минимум CSRF-атаки.

Вам нужно быть в курсе обо всех, и вы хотите. Оба атакуют не все, о чем вам нужно знать, просто помните: ВЫ БЕЗОПАСНО КАК МЕНЬШЕ БЕЗОПАСНАЯ ТОЧКА ВАШЕГО ПРИЛОЖЕНИЯ.

Вновь сохранение в порядке, быть уязвимым для XSS, CSRF,... не

Ответ 6

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

Подресурсная целостность (SRI) - это функция безопасности, которая позволяет браузерам проверять, что ресурсы, которые они выбирают (например, из CDN), доставляются без неожиданных манипуляций. Он работает, позволяя вам предоставить криптографический хеш, которому должен соответствовать извлекаемый ресурс.

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

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

Ответ 7

Чтобы посмотреть на это, нужно учитывать уровень риска или вреда.

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

Создаете ли вы версию 2 приложения со многими ежедневно активными пользователями или приложение, от которого сильно зависят люди/компании. Будет ли хакерство означать мало или нет места для восстановления? Если это так, я бы внимательно посмотрел на ваши зависимости и рассмотрел вопрос о сохранении информации о токене в файле cookie только для http.

Использование локального хранилища и хранилища файлов cookie и сеансов имеет свои плюсы и минусы.

Как указано в первом ответе: если ваше приложение имеет уязвимость XSS, ни один из них не защитит вашего пользователя. Поскольку большинство современных приложений имеют дюжину или более различных зависимостей, становится все труднее гарантировать, что одна из ваших зависимостей приложений не будет уязвимой для XSS.

Если ваше приложение имеет уязвимость XSS, и хакер смог использовать ее, он сможет выполнять действия от имени вашего пользователя. Хакер может выполнять запросы GET/POST путем получения токена из localStorage или может выполнять запросы POST, если токен хранится в файле cookie только для http.

Единственным недостатком хранения вашего токена в локальном хранилище является то, что хакер сможет прочитать ваш токен.