Comments 42
Вообще-то на 3 порядка
cookies должны быть созданы сервером.
Они могут быть созданы и клиентом.
Недостатки
Не работает в Сафари в порно режиме.
Конечно, можно переводить все типы данных в строки, но это безобразное решение.
Сериализация данных — вполне нормальное решение.
если хакер сможет запустить JavaScript-код на вашем сайте, то
Он сможет получить любую доступную пользователю приватную информацию, независимо от того используете ли вы localStorage или нет. И CSP конечно же не спасёт, ибо есть куча способов переслать себе данные через сам же атакуемый сайт.
Наверняка ваш сайт содержит скрипты, которые загружаются с других серверов.
Весьма необоснованное предположение. Те, кто пекутся о безопасности пользовательских данных и стабильности работы никакие сторонние скрипты не подключают.
Никто не сможет запустить какой-либо скрипт на моем сайте". И вот тут загвоздка. В теории вы абсолютно правы, однако на деле этого фактически невозможно достичь.
Можно. Если вы не знаете как — это не значит, что это невозможно.
Те, кто пекутся о безопасности пользовательских данных и стабильности работы никакие сторонние скрипты не подключают.Все дружно передаем привет Сбербанку.
автор не говорит, что "Никто не сможет запустить какой-либо скрипт на моем сайте". он как раз приводит это утверждение и говорит, что оно неверное.
Я где-то читал, что localStorage используют также для кеширования ресурсов. Получается вообще ничего хранить нельзя. Всё могут изменить и прописать зловред. Что там хранить тогда, CSS и шрифты?
Согласен в том, что сид лучше хранить в печеньках с httpOnly. Остальное выглядит прохладно, если вы грузите чужой js это автоматом значит что уже ничего не спасёт, поменять форму логина, никто те запрещал
Сегодня Web-стек не может предоставить инструментов надлежащей доставки авторизованного контента. Список актуальных атак:
- подмена или модификация HTTP-траффика, в некоторых случаях и HTTPS.
- взлом сервера отдающего веб-интерфейс.
- подмена DNS.
- воровство аккаунта сервис провайдера для подмены трафика.
если хакер сможет запустить JavaScript-код на вашем сайте
То localStorage это наименьшая из ваших проблем с точки зрения безопасности, ибо код сможет вделать почти всё то, что и пользователь.
Чтобы тот же JWT сохранялся между перезагрузками страницы, а не предлагал пользователю логиниться каждый раз как он F5 нажмёт.
Разве куки будут сбрасываться при перезагрузке страницы?
Во-первых, как уже было сказано выше, Cookie — ~4kB
т.е. 4k char
. В среднем, я не использовал JWT токены длинее 2k символов, но это не показатель, и ваш JWT может быть и в 8kB.
Во-вторых, cookie постоянно гоняются по сети, даже если вы этого не хотите (fetch
и XMLHttpRequest
не в счет, там по умолчанию false
).
Честно признаюсь, я не так чтобы очень разбираюсь в безопасности, но некоторые тезисы вызывают сомнения.
Может содержать только строки, что делает его совершенно бесполезным, если речь идёт хоть о чем-то сложнее строк. Конечно, можно переводить все типы данных в строки, но это безобразное решение.
«Протокол HTTP может передавать только строки, что делает его совершенно бесполезным, если речь идет хоть о чем-то сложнее строк.» Ок, HTTP, может быть, не самая прекрасная вещь на свете, но ведь вполне рабочая.
Оно синхронно. Это означает, что каждая операция, связанная с хранилищем, будет выполняться последовательно. Для сложных приложений это критично, поскольку может замедлить скорость его работы.
Хотелось бы пример, что такое можно делать с localStorage, чтобы оно тормозило, записать туда 5-меговый блоб? «Тормозит потому что не асинхронное» это не аргумент, должны быть какие-то цифры или хотя бы ссылки.
Его не могут использовать web workes. То есть если вы создаете приложение, использующее преимущества фоновой обработки для производительности, расширение для Chrome или прочие подобные вещи, то локальным хранилищем воспользоваться, увы, не выйдет.
Писать и читать из расширения Chrome в localStorage вполне возможно, content scripts имеют доступ к хранилищу страницы. Другое дело что для хранения настроек самого расширения лучше взять chrome.storage.sync (а когда этого API не было, все всё хранили в localStorage background_page).
Но как это связано с веб-воркерами? И почему нельзя передать данные из хранилища в web worker, а он там пусть их в фоне обрабатывает?
Убедитесь, что у cookie-библиотеки, которую использует ваш фреймворк, в настройках включено “httpOnly”.
Разумно. Но при чем тут клиентский JS?
НедостаткиАПИ не вызывает сетевых запросов, скорей всего не вызывается даже чтение с диска при каждом обращении. Звучит так, что человек хочет асинхронное обращение к полям объекта.
Оно синхронно. Это означает, что каждая операция, связанная с хранилищем, будет выполняться последовательно. Для сложных приложений это критично, поскольку может замедлить скорость его работы.
Одна из неприятных вещей, касающихся cookies (которые, по сути, являются единственной реальной альтернативой локальному хранилищу) заключается в том, что они должны быть созданы сервером. Ужас, ведь работа с веб-серверами скучна и трудоёмка.Очень эмоционально и абсолютно неверно, как и почти вся статья.
localStorage располагает как минимум 5 Мб для хранения данных (этот размер поддерживается всеми основными веб-браузерами), что на порядок больше, чем у cookie-файлов (~ 4 Кб)
Занудство: на три порядка больше. Но я восхищаюсь темпами развития технологии, при которых прирост в 10 раз вообще ничего не значит, а переход от килобайтов к мегабайтам — это переход «на порядок». Предлагаю придумать новое русское выражение, которое бы передавало смысл фразы «на порядок больше» при сравнении килобайтов с мегабайтами.
При такой схеме мы всё так же можем узнать пользователя без запроса к базе (что полезно в условиях микросервисной архитектуры). Также можно реализовать отзывание токена за счёт цепочки токенов и малого срока действия (несколько минут).
С другой стороны это довольно сложная система, и, возможно, проще просто завести отдельный сервис аутентификации.
Если хакер сможет запустить JavaScript-код на вашем сайте, то он запросто вытащит всю информацию из localStorageЕсли хакер сможет запустить JavaScript-код на моём, он итак сможет вытащить всё что угодно да и вообще сделать всё что угодно. Server-only кука не спасёт — хакер просто пошлёт запрос к главной странице (куки будут успешно отсылаться, т. к. origin совпадает), возьмёт нужные хэши и далее будет посылать запросы к методам — уже и вместе с хэшами, и вместе с куками. При этом самих кук у него не будет, но они ему и не очень-то нужны.
Конечно же, это только один из вариантов, можно придумать ещё 100500 вещей, что можно сделать с javascript. В общем обычные куки не выглядят сильно безопаснее даже с режимом http-only.
Впрочем, какая-то разница всё-таки есть — если можно угнать именно саму сессию, то что с ней делать можно подумать потом, а с http-only куками надо сделать делать всё сразу, и для этого нужно знать структуру сайта уже до проведения атаки.
Оно синхронно. Это означает, что каждая операция, связанная с хранилищем, будет выполняться последовательно.
А что, обернуть код [хотя бы] в promise уже не судьба?
поскольку поставщики этих скриптов частенько их меняют для расширения функционала и прочих вещей
Все адекватные поставщики скриптов указывают версию скрипта. И если я поставил версию 2.3.456 с указанием Integrity, ссылка на неё должна оставаться неизменной. Тут больше вопрос использования адекватных библиотек.
Насколько я понял, localStorage нужно использовать, и отказаться от него не панацея. Панацея будет если защититься от XSS и CSRF атак..?
Почему не стоит использовать LocalStorage