Как защитить от CSRF конечные точки входа и регистрации (представления) API, созданные с помощью DRF, которые используют JWT в качестве аутентификации?

Я искал и читал другие вопросы и блоги, но не нашел ничего конкретного по поводу моих сомнений.

Немного контекста:

Я разрабатываю SPA, который работает с REST API на Django с помощью Django Rest Framework (DRF) и аутентификация осуществляется через Bearer token: JWT (пакет 'Simple JWT'). Итак, я читал, нужна ли защита от CSRF:

- Нужен ли мне CSRF токен, если я использую Bearer JWT?

- Нужно ли использовать защиту CSRF на конечных точках Rest API?

- Руководство по аутентификации Web API, токены Bearer

По сути, если браузер не производит автоматическую аутентификацию (с помощью сессий или какого-то куки), вероятность CSRF-уязвимости мала. Этот подход достигается с помощью Bearer Tokens, использующих JWT внутри заголовка 'Authorization'.

Обновлено: На данном этапе разработки настроен Django-CORS, но в продакшене будет настроен прокси через Nginx. Избегая CORS атак.

Проблема:

Есть некоторые публичные конечные точки, которым не нужна аутентификация, поэтому я использовал это разрешение в настройках DRF

"DEFAULT_PERMISSION_CLASSES": ['rest_framework.permissions.IsAuthenticatedOrReadOnly'],

Таким образом, неавторизованные пользователи могут делать только безопасные запросы -методы: GET, HEAD и OPTIONS-. Пользователи, имеющие JWT, могут выполнять любые запросы.

Представления

Login и register работают через POST запросы, связанные с изменением состояния приложения. Проблема в том, что вышеуказанное разрешение позволяет избежать того, что "анонимный" (чтобы как-то назвать его) пользователь не сможет зарегистрироваться или войти. Вопрос в том, как мне их защитить?

Я думал о том, чтобы изменить разрешение для этих представлений на 'AllowAny'. Но я не знаю, вернет ли это беспокойство по поводу CSRF, потому что здесь нет токена Bearer, или, возможно, других уязвимостей безопасности, которые я даже не могу себе представить.

Другая возможность - использовать CSRF-токен только в этих представлениях.

Или есть ли лучший подход для защиты этих двух конечных точек?

Надеюсь, кто-нибудь сможет мне помочь!

Вы можете использовать CSRF-токены в своих формах входа и регистрации, и это достаточно защитит вас от CSRF-атак на эти конечные точки. В этом случае вам придется разрешить анонимный доступ к этим конечным точкам. Обычно конечные точки входа и регистрации не находятся за брандмауэром и доступны анонимным пользователям.

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