Комментарии 9
По поводу безопасности.
Localstorage более уязвим к потере данных, так как при проведении успешной XSS атаки - данные будут легко угнаны. Это можно прочитать в любом месте, где сравниваются куки и локальное хранилище в разрезе хранения токена.
Но штука в том, что даже если мы используем httpOnly cookie, с атрибутами sameSite и прочими вещами - всё равно при успешной XSS атаке данные токена будут не в безопасности.
Есть потрясающая статья с Highload 2017 про уязвимость к CSRF атакам - https://habr.com/ru/companies/oleg-bunin/articles/412855/. Она всё ещё актуальна. Там в самом низу отличная табличка и наглядно видно, что если словили XSS то нас уже ничего не спасёт ))
Т.е. не важно какой способ хранения токена выбрали - если словили xss, то имеем большой риск потери токена.
В реальности, где атакеры понимают способы обхода угона токенов из кук через обход csrf защиты, основным и наиболее надёжным способом защиты токенов является защита от XSS атак и ограничение времени жизни токена. И кажется ещё двухфакторная аутентификация )))
Я не призываю использовать сторадж для решения задачи хранения токена. Это всего лишь один из возможных вариантов. Как и сказано выше - это менее безопасно нежели куки. Однако реальный мир много сложнее чем "правильно/не правильно" и использование базовых рекомендаций вообще не гарантирует безопасности.
Надеюсь эти выводы и статья помогут натолкнуть на некоторые размышления и породят вопросы, которые приведут к росту количества знаний/опыта (по крайней мере для меня это сработало именно так).
thx)
PS:
Некоторые из простых и понятных правил, которые можно применять для того, чтобы сделать чуть безопаснее (список не полный, так как безопасность приложений не моя специализация):
https использовать
санитайзеры (по типу https://github.com/leizongmin/js-xss)
очень внимательно и ограниченно юзаем dangerouslySetInnerHTML
ограничиваем кол-во чувствительной инфы, хранимой на клиенте и срок её жизни
имеем в команде хорошего бекендера, который шарит за безопасность так же
...
PPS: для приложений, которые используют карточные данные есть целый набор рекомендаций по безопасности, который называется PCI DSS
Локальное хранилище же по-прежнему не отсылает своё содержимое в первом запросе к серверу? В таком случае оно менее удобно в случае, если в ходе server side rendering загружается первый экран приложения - пользователя придётся логинить уже по мере прогрузки страницы.
Вообще для ssr адаптации не делал.
Кажется надо будет слегка доработать WithAuth для этих кейсов.
WithAuth попробует тебя авторизовать и если не получится - перенаправит на страницу логина. Если токена не найдёт - отправит апи запрос. Во время ssr этот запрос должен пройти нормально и токен появится и children зарендерятся - т.е. ssr случится. Но токен этот не сохранится, так как нет локалстораджа.
Надо кажется спустить вниз (во фронт) этот токен, если он был подтянут вовремя ssr и там уже на клиенте его сохранить в сторадж и вроде все кейсы покрыты будут.
Хорошее примечание, спасибо)
Все вызовы к localStorage лучше оборачивать в try-catch, иначе можно поймать различные багули с доступом, например, в FF
хм. Судя по всему речь идёт об очень старых версиях firefox - с версии 3.5 (от 2009) уже гарантируется доступность глобал объекта
https://caniuse.com/?search=localStorage
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Кажется этим можно пренебречь, так как количество пользователей браузеров 2009 года в 2023 стремится к нулю)
А сам метод хранилища нам отдаст null если не найдёт там значения https://developer.mozilla.org/en-US/docs/Web/API/Storage/getItem
Если идет общение SPA с API, почему не обязать сервер передавать защищенную куку, которую браузер и так будет цеплять к fetch запросам, а сервер валидировать?
Хранить токен в localstorage, куда имеет доступ все, что связано с js, в том числе подключаемые внешние скрипты/метрики/пиксели gtm тот же... Даже с учетом наличия абстракции все еще не безопасно, темболее нельзя исключать человеческий фактор, что кто-то когда-то в очередной версии клиента случайно опустит абстракцию и допустит обработку внешнего html например и кто-то подкинет пиксель с js пользователю.
почему не обязать сервер передавать защищенную куку, которую браузер и так будет цеплять к fetch запросам, а сервер валидировать
да можно конечно) и для множества сценариев это будет чуть более безопасно)
но статья не про сравнение куки vs localstorage, а про то, как можно юзать localstorage если такой выбор был сделан)
По поводу безопасности.
Localstorage более уязвим к потере данных, так как при проведении успешной XSS атаки - данные будут легко угнаны. Это можно прочитать в любом месте, где сравниваются куки и локальное хранилище в разрезе хранения токена.
Но штука в том, что даже если мы используем httpOnly cookie, с атрибутами sameSite и прочими вещами - всё равно при успешной XSS атаке данные токена будут не в безопасности.
Есть потрясающая статья с Highload 2017 про уязвимость к CSRF атакам - https://habr.com/ru/companies/oleg-bunin/articles/412855/. Она всё ещё актуальна. Там в самом низу отличная табличка и наглядно видно, что если словили XSS то нас уже ничего не спасёт ))
Т.е. не важно какой способ хранения токена выбрали - если словили xss, то имеем большой риск потери токена.
В реальности, где атакеры понимают способы обхода угона токенов из кук через обход csrf защиты, основным и наиболее надёжным способом защиты токенов является защита от XSS атак и ограничение времени жизни токена. И кажется ещё двухфакторная аутентификация )))
Я не призываю использовать сторадж для решения задачи хранения токена. Это всего лишь один из возможных вариантов. Как и сказано выше - это менее безопасно нежели куки. Однако реальный мир много сложнее чем "правильно/не правильно" и использование базовых рекомендаций вообще не гарантирует безопасности.
Надеюсь эти выводы и статья помогут натолкнуть на некоторые размышления и породят вопросы, которые приведут к росту количества знаний/опыта (по крайней мере для меня это сработало именно так).
thx)
PS:
Некоторые из простых и понятных правил, которые можно применять для того, чтобы сделать чуть безопаснее (список не полный, так как безопасность приложений не моя специализация):
https использовать
санитайзеры (по типу https://github.com/leizongmin/js-xss)
очень внимательно и ограниченно юзаем dangerouslySetInnerHTML
ограничиваем кол-во чувствительной инфы, хранимой на клиенте и срок её жизни
имеем в команде хорошего бекендера, который шарит за безопасность так же
...
PPS: для приложений, которые используют карточные данные есть целый набор рекомендаций по безопасности, который называется PCI DSS
localStorage для авторизации