Csrf с локалсторейджем не получится

Там нет твоей сессии в куках

Т.к. он не бегает с каждым запросом

https://learn.javascript.ru/csrf

Но если ты хранишь в обычной куке, а потом достаешь в js, и кладёшь ручками в запрос, то csrf тоже не проканает

Csrf с локалсторейджем не получится

ПОЧЕМУ?

ПОЧЕМУ?

Потому что сервер будет из тела запроса брать токен

А не из куки

Кука просто как хранилище

У нас токен в куке потому что ssr и надо чтобы сервер рендерил то же самое

И что мешает стороннему скрипту это симитировать?

И что мешает стороннему скрипту это симитировать?

Стороннему, или при xss-атаке?

При csrf атакующий не получает никаких данных

Он просто делает запрос, а твой сервак берет куку и авторизирует

При xss же чувак сможет получить именно value токена

Ну и тогда, конечно, вам пизда

когда ты шлешь запрос к бекенду у тебя вместе с ним отправляется кука, локалсторадж никуда не отправляется. поэтому при csrf неожиданно для тебя могут твоими руками послать запрос к бекенду с которым убежит и твоя кука)

Таааак. Ну я собрал инфу по Security Отличие cookie от localStorage. https://github.com/artalar/blog/blob/master/src/pages/notes.md#%D0%9E%D1%82%D0%BB%D0%B8%D1%87%D0%B8%D0%B5-cookie-%D0%BE%D1%82-localstorage

Т.е. хранить токен в сторедже - нормально?

Абсолютно

но от этого можно защититься, а вот от доступа сторонними скриптами к токену в локалсторадже не получится)

Т.е. хранить токен в сторедже - нормально?

Да, но есть нюансы

Лучше хранить в хиден полях форм

Для сабмита

Так owasp советует делать

Но это всегда подходит

Лучше хранить в хиден полях форм

xss даст пизды все равно

Поэтому это нормально хранить в локалсторадже

csrf токен имеется ввиду наверно )

Много серьезеых ресурсов так делает

его хоть где храни )

когда ты шлешь запрос к бекенду у тебя вместе с ним отправляется кука, локалсторадж никуда не отправляется. поэтому при csrf неожиданно для тебя могут твоими руками послать запрос к бекенду с которым убежит и твоя кука)

Ну а что мешает предварительно взять чужому скрипту токен из локалСтораджа?

Именно

при csrf ?

Ну а что мешает предварительно взять чужому скрипту токен из локалСтораджа?

Ты путаешь csrf и xss

Скрипт надо исполнить на станице твоего домена

Сначала надо xss успешно провернуть

Для такого

Ну а что мешает предварительно взять чужому скрипту токен из локалСтораджа?

если они реализовали xss то csrf им уже не надо )))

Для этого реакт экоанирует все строки

Пользовательсклго ввода

Для этого реакт экоанирует все строки

и этого тоже мало, сторонний скрипт в любой момент может прочитать твой локалсторадж

Ващм где хочет там и храни

Если ты банк то под каждыц запрос выпускай токен

Одноразовый

И гоняй их туда сюда

Не храня вообще

В общем надо токен хранить в куке, но AES его ключем, который рандомно бекенд при инициализации прислал. При этом ключ, соответственно, держать в замыкании и использовать каждый раз при необходимости своих запросов. Все

У нас токен в куке потому что ssr и надо чтобы сервер рендерил то же самое

Ты где раньше был с таким аргументом?)

Это ж реально важно

хороший аргумент да)

Ты где раньше был с таким аргументом?)

Ну, скажем, серверу и не обязательно рендерить те части, которые user-specific

Но с этим геморно

В общем надо токен хранить в куке, но AES его ключем, который рандомно бекенд при инициализации прислал. При этом ключ, соответственно, держать в замыкании и использовать каждый раз при необходимости своих запросов. Все

ша добавлю в статью

заметку*

Но с этим геморно

Потому что оно будет появляться только при клиентском рендеринге, как бы "прыгая"

Потому что оно будет появляться только при клиентском рендеринге, как бы "прыгая"

м?

Потому что оно будет появляться только при клиентском рендеринге, как бы "прыгая"

персистить в локалсторадж можно

Ну типа сервер отрендерил без рекламного предложения, которое мы показываем только юзерам категории Х, а клиент уже только в componentDidMount полез и срендерил его

redux-persist без дерганий делает

И получается сайт загрузился, а потом только появился баннер

А не сразу страница с баннером

персистить в локалсторадж можно

Я не про это

Ну да ладно, это не сильно важно

ну мб если кому то это очень существенно для задачи

Так, а для XSS и CSRF разницы в куках и локалсторадже нет?

Так, а для XSS и CSRF разницы в куках и локалсторадже нет?

Csrf возможен только если авторизация происходит СУГУБО посредством чтения кукисов из заголовка Cookies

Как, например, с http only кукой

ERROR: S client not available

Понял

Выходит HttpOnly не панацея

А вы говорили

Да, она подвергает csrf-атакам

Но они менее страшные, чем xss

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

Но они менее страшные, чем xss

Но xss в разы сложнее провернуть

Так что тут палка о двух концах

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

пчму?

Но xss в разы сложнее провернуть

Так xss и для кук и для локалсторадж страшен?

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

получаешь временный токен на скачивание этого файла и погнал)

Так xss и для кук и для локалсторадж страшен?

Xss сработает если ты хоть как-то можешь из js получить значение токена

Http only кука - способ не иметь такой возможности

Но она подвергает csrf-атакам

Потому что вы ВЫНУЖДЕНЫ авторизовать через заголовок Cookies

Ок

пчму?

загрузить файлы можно двумя способами - через установку хедера Content-Disposition или через загрузку блобов через xhr/websoket-ы но только гигабайтные файлы через xhr/websocketы передать не получится а через Content-Disposition авторизироваться можно только через куки

В общем надо токен хранить в куке, но AES его ключем, который рандомно бекенд при инициализации прислал. При этом ключ, соответственно, держать в замыкании и использовать каждый раз при необходимости своих запросов. Все

К этому способу притензий нет?

загрузить файлы можно двумя способами - через установку хедера Content-Disposition или через загрузку блобов через xhr/websoket-ы но только гигабайтные файлы через xhr/websocketы передать не получится а через Content-Disposition авторизироваться можно только через куки

Ок О_о

Спасибо

К этому способу притензий нет?

Лишний запрос при инициализации, ssr

а это про аплоад))

В общем надо токен хранить в куке, но AES его ключем, который рандомно бекенд при инициализации прислал. При этом ключ, соответственно, держать в замыкании и использовать каждый раз при необходимости своих запросов. Все

Хотя аплоад работать не будет((((

А, не, будет

уффф

Лишний запрос при инициализации, ssr

С ssr прям не обойти, нельзя, разве, дождать запроса первого?

Просто зашифровав куку один раз неким ключом, расшифровать ты его сможешь только с тем же ключом

так, где все-таки хранить токен то? к чему пришли?

так, где все-таки хранить токен то? к чему пришли?

есть нюансы

Просто зашифровав куку один раз неким ключом, расшифровать ты его сможешь только с тем же ключом

Так сервак контролирует все

Не вижу проблемы

так, где все-таки хранить токен то? к чему пришли?

Ша, пишу заметку, все подробно будет