Dj rest auth с использованием JWT-токена, хранящегося в cookies HttpOnly

Я делаю приложение на Django Rest Framework с JWT-аутентификацией с токенами, хранящимися в куках HttpOnly. Аутентификация осуществляется через чтение куки access. Я использую для этого библиотеку dj-rest-auth, но меня немного смущает аспект безопасности такого метода. Зная, что аутентификационные данные, хранящиеся в cookies, могут быть использованы для проведения CSRF атаки, как можно защитить свой веб от таких атак для конкретного случая, который я описал выше? Все куки настроены на SameSite=Lex.

Нужно ли мне также отправлять заголовок X-CSRFTOKEN, полученный из бэкенда? Это означает, что каждый запрос к api должен будет содержать этот заголовок. Какой должна быть оптимальная установка с использованием всех этих библиотек?

Фонд OWASP создал подробную шпаргалку о том, как защититься от CSRF-атак: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Две вещи, которые стоит запомнить:

  • CSRF касается только запросов, изменяющих данные, поэтому методы POST/PUT/PATCH/DELETE. Злоумышленник, выполняющий CSRF-атаку, не может прочитать ответ сервера, поэтому GET-запросы вас не касаются.

    .

  • Наиболее распространенным способом предотвращения CSRF является использование токена csrf. Сервер должен создать токен для сессии пользователя, и токен сохраняется во фронтенде, но не в куки. Затем вы отправляете этот токен либо в заголовке, либо как часть тела запроса. Затем сервер проверяет, что токен такой же, как и тот, который он имеет для данной пользовательской сессии.

Если вы не хотите сохранять токен на сервере, вы можете дополнительно сохранить его в cookie. Таким образом, фронтенд будет хранить токен в двух местах - один в памяти/в скрытом поле формы/и т.д., а другой в куки. Затем сервер может проверить, совпадает ли значение из cookie со значением из header/body.

Все cookies установлены на SameSite=Lex.

Нужно ли мне также отправить заголовок X-CSRFTOKEN, полученный из бэкенда?

SameSite не поддерживается старыми браузерами. По данным caniuse, он поддерживается 90% браузеров, используемых во всем мире.

Аргументы ПРОТИВ внедрения CSRF-токенов:

  • Я думаю, что это низкий риск. Если вы думаете, что ваши пользователи будут среди этих 90%, то не стоит беспокоиться о CSRF-токенах.
    • .
  • Поскольку вы используете JWTs, я предполагаю, что фронтенд будет современным SPA-приложением. Если вы не ожидаете, что оно будет работать на старых браузерах, то, опять же, не стоит беспокоиться о CSRF-токенах.

Аргументы ЗА внедрение CSRF-токенов:

  • Lax не обеспечивает никакой защиты при GET-запросах. Вам придется убедиться сегодня и в будущем, что вы никогда не изменяете состояние сервера в GET-запросах. Если вы внедрите CSRF-токены, у вас будет на одну заботу меньше. Или вы также можете использовать SameSite=Strict value.

Мое мнение:

Лично я бы просто внедрил CSRF-токены. Это одноразовая настройка, и большинство фреймворков уже позаботились об этом. Так почему бы и нет?

P.S.: Я не уверен, что у вас там опечатка, но это Lax, а не Lex.

Вернуться на верх