Как стать автором
Обновить

Комментарии 19

connect-src service.test *.google-analytics.com mc.yandex.ru;
Тут ошибка. mc.yandex.ru это только один из доменов метрики. Для пользоватей из других регионов метрика перестанет работать. Самое неприятное здесь это то что нельзя применить плейсхолдеры как у Гугл аналитики, потому что метрика не использует поддомены. Перечислять все 20+ доменов метрики в заголовках это дичь. К тому же они могут измениться.
Поэтому придётся полностью отказаться от CSP либо от метрики.
Безусловно, вы правы. Для регионов надо указывать альтернативные домены (которые есть в документации яндекса), в статье я привёл ознакомительный пример конфига. Не думаю, что стоит совсем отказываться от CSP или метрики. Тут всё зависит от направленности самого приложения и тем, на сколько часто будут возникать блокировки csp. Если такие визиты единичны, то ими можно пренебречь.
Вам надо что-то с ручками делать…
Лучше вы поясните, что вы имели в виду под ручками в вашем тексте (переводе?)… поищите, если вы читали его, конечно))

REST API ручками
Пусть ручка получения POST
В ручке POST
дак у буржуев эт endpoint же…
С буржуями всё понятно, и с точками входа, и с обработчиками и другими адекватными словами-переводами и не очень. Но вот ручка… даже по смыслу бред, ручка двери только на ум приходит. Откуда этот «сленг»?)

В паре проектов, в которых я участвовал сленговое "ручка" тоже вполне себе использовалось. Цепочка аналогий такая: у нас есть метод, что-то обрабатывающий, он же handler -> hand -> ручка :)

Ручка — это endpoint API-интерфейса. Например GET /user — endpoint получения информации о пользователе. В русском языке закрепился немного сленговый термин «ручка»)
В русском языке закрепился немного сленговый термин «ручка»
Первый раз про него слышу.

Я полагаю имелось ввиду = handle

handle как "ручка" тоже нечасто переводится. Обычно это "дескриптор".

НЛО прилетело и опубликовало эту надпись здесь
Принял ваше замечание, спасибо) исправил. Надеюсь, так понятнее)
Хранение refresh_token в любых куках плохая идея. А тут ещё он превратился из токена в обычную сесионую куку, которой и нужна защита от CSRF. Ну и дальнейшая идея использовать в качестве CSRF токена протухший acess-token ещё хуже.
В статье я как раз говорил, что хранить надо только в httpOnly. Это не совсем сессионная кука, это кука, нужна только для обновления токена доступа. Если злоумышленник не будет иметь прежний токен доступа (который не достать csrf атакой), то воспользоваться рефреш токеном он не сможет.
Признак httpOnly говорит только о том, что эта кука недоступна из javaScript и для всех запросов она работает как обычная кука. CSRF как раз и основан на автоматической отправке кук, и для него глубоко паралельно она htpOnly или нет. Поэтому ваш refresh-token для CSRF ПОЛНОСТЬЮ аналогичен обычной куке.
В обычной ситуации считается, что access-token может быть перехвачен, но из-за его короткого действия похититель ним воспользоваться не может (не успеет). А вот своровать refresh-token сложно (в идеале вообще невозможно). А у вас вы refresh-token положили вору на блюдечке (он отдается автоматически при запросе), да ещё и разрешили воспользоваться протухшим acces-token — это просто праздник для хакера.
ЗЫ: При разработке системы безопасности есть основное правило: ЕСЛИ ВЫ НЕ ЭКСПЕРТ ПО БЕЗОПАСНОСТИ СЛЕДУЙТЕ ИНСТРУКЦИИ И НЕ ПРИДУМЫВАЙТЕ СВОЮ СИСТЕМУ, ТАК КАК В ВАШЕЙ СИСТЕМЕ С ВЕРОЯТНОСТЬЮ 100% ЕСТЬ ДЫРА. :)
Каким образом в этой схеме злоумышленник с помощью одного лишь csrf-атаки прочитает токен, хранящийся в httpOnly cookie? Он может послать запрос через браузер с этой куки в заголовке, не отрицаю. Но что он этим добьётся? Как вы верно заметили, такую куку он с помощью js прочитать не сможет. А одного рефреш токена не достаточно для того, чтобы выполнить какое-либо действие или получить пользовательские данные.

ЗЫ: Нужно больше капса)
Мне кажется если вы критикуете в чем то оппонента, то может стоит предложить верный алгоритм, хотя бы в одной фразе?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий