Comments 4
Всегда думал, что CSRF атаки уже лет 10 как не актуальны
Оговорюсь, здесь и далее в куках все параметры с __Secure-, Secure, SameSite=Lax
Недавно сам плотно изучал вопрос и вот к какому решению пришел:
1. Берем JWT токен и засовываем его в cookie с флагом httpOnly (JWT нужен для сервисов, которыми пользуется наш бэкенд, а для информации о пользователе создаем endpoint me)
2. Генерируем обычный CSRF токен и кладем его в JWT, и параллельно отправляем вместе с токеном в куки, но без httpOnly
В момент запроса просто берем CSRF токен из куки, и отправляем на сервер. Там проверяем валидность JWT, и все 3 CSRF токена должны совпасть: в куки, в запросе в JWT.
Почему так?
1. JWT - подписанные данные и знакомая многим концепция, его время жизни тоже заложено в нем, а потому не страшно, что пользователь руками продлит куку.
2. Снижена нагрузка на сервер, ибо в JWT можно положить всякой полезной информации, чтобы не бегать в базу.
3. Не нужно хранилище для токенов, они не будут жить дольше самого JWT, который рассчитан на 10-15 минут.
4. Между вкладками и сессиями CSRF токен у нас актуален.
Безопасность в деталях: исследование cистемы защиты от CSRF