Вопрос или проблема
Будет ли случайно сгенерированный ключ сеанса достаточным, чтобы я мог прекратить использование CSRF токена? Фронтенд получит токен при входе в систему. Он будет храниться в «локальном хранилище» на устройстве клиента и проверяться при каждом запросе к серверу. Он будет действовать в течение заданного времени, и после выхода из системы вы завершите сеанс.
Все сеансы будут сохраняться в базе данных сервером. Сервер будет искать эти ключи с данными из запросов. Он будет возвращать данные на фронтенд, если ключ действителен.
Будет ли это безопасно? Или есть какие-либо слабые места в этой архитектуре?
CSRF представляет собой угрозу только в случаях с учетными данными, которые отправляются автоматически, или в других случаях, когда авторизация предоставляется автоматически (например, по IP-адресу). Следовательно, куки являются обычным случаем, когда CSRF является проблемой, но также и такие вещи, как клиентские TLS-сертификаты, IPSec, аутентификация в домене Windows (Kerberos) и HTTP Basic или Digest аутентификация также могут быть уязвимы (это не обязательно исчерпывающий список).
В вашем случае, поскольку токен сеанса хранится в локальном хранилище, его, предположительно, не хранят в куки. Таким образом, запросы должны явно добавлять токен где-то – обычно как значение заголовка Authorization: Bearer, но иногда в другом заголовке или даже в теле – потому что браузер не будет автоматически добавлять содержимое локального хранилища к запросам так, как он автоматически добавляет куки (или некоторые другие учетные данные, такие как указанные выше) к запросам.
Таким образом, ваш приложение по своей сути защищено от CSRF, если ваши учетные данные отправляются только явно, а не автоматически. Атакующий не может добавить токен сеанса в поддельный запрос, не зная, что это такое, и если он это знает, он может просто захватить сеанс напрямую, а не обманывать ваш браузер, чтобы он что-то сделал.
Ответ или решение
Безопасность сессий без CSRF-токенов: Использование сессионных токенов
В современных веб-приложениях безопасность пользовательских сессий является одной из главных задач. Использование CSRF-токенов стало стандартной практикой для защиты от атак, направленных на подделку запросов. Тем не менее, в некоторых случаях возможно использовать альтернативные подходы к управлению сессиями. В данном контексте мы рассмотрим, насколько безопасно заменить CSRF-токены на случайно сгенерированные сессионные ключи, хранящиеся в локальном хранилище.
Как это работает
При входе в приложение пользователю предоставляется сессионный токен, который хранится в локальном хранилище браузера. Токен отправляется с каждым запросом к серверу и проверяется на стороне бэкенда. Сессии хранятся в базе данных, и сервер проверяет действительность токена. При завершении сеанса или выходе пользователя из системы токен уничтожается.
Безопасность архитектуры
Вам необходимо понимать, что сессии, хранящиеся в локальном хранилище, не подвержены CSRF-атакам по следующим причинам:
-
Явная передача токена: В отличие от куки, которые автоматически включаются в запросы браузера, токены из локального хранилища необходимо явно добавлять в заголовки запросов (например, в заголовок
Authorization: Bearer). Это делает практически невозможным выполнение CSRF-атак, поскольку злоумышленник не может заставить браузер отправить этот токен без доступа к нему. -
Отсутствие автоматической передачи: Куки, используемые браузерами, автоматически отправляются на сервер при каждом запросе к домену. Таким образом, они уязвимы для CSRF-атак. Ваша архитектура, предполагающая хранение токенов в локальном хранилище, устраняет эту уязвимость.
Потенциальные уязвимости
Тем не менее, стоит обратить внимание на некоторые ограничения и потенциальные проблемы:
-
Уязвимость к XSS: Если ваше приложение имеет уязвимости для XSS (Cross-Site Scripting), злоумышленники могут получить доступ к токенам в локальном хранилище, что приведёт к угону сессии. Поэтому важно использовать методы защиты, такие как Content Security Policy (CSP) и регулярное сканирование кода на наличие XSS-уязвимостей.
-
Хранение в локальном хранилище: Локальное хранилище имеет свои ограничения. Данные в нём могут быть доступны не только вашему приложению, но и любому коду, выполняемому в контексте этого домена. Поэтому необходимо тщательно управлять доступом к этому хранилищу и проверять вводимые данные.
-
Срок действия токена: Убедитесь, что сессионные токены имеют ограниченное время жизни и могут быть отозваны из базы данных в любое время. Это уменьшает риск, связанный с угоном токенов.
Рекомендации
Для повышения безопасности вашей архитектуры рекомендуется следующее:
- Реализуйте дополнительные меры защиты, такие как регулярное использование HTTPS для предотвращения MITM-атак (атаки "человек посередине").
- Применяйте механизмы защиты от XSS и корректно обрабатывайте вводимые данные, чтобы минимизировать уязвимости.
- Предусмотрите механизмы отслеживания сессий и многослойной аутентификации, если это применимо к вашему проекту.
- Регулярно обновляйте вашу архитектуру и следите за новыми стандартами безопасности.
В итоге, замена CSRF-токенов на сессионные токены, хранящиеся в локальном хранилище, может быть безопасной стратегией, но требует правильной реализации и учёта всех возможных угроз. Обеспечив защиту от XSS и следуя современным практикам безопасности, вы существенно снизите вероятность успешных атак на ваше веб-приложение.