Нужна ли мне защита от CSRF для конечной точки /login?

Я знаю

этот вопрос уже задавался так много раз, но после нескольких часов поиска у меня все еще нет четкого ответа на мою проблему.

Даже такие проекты, как https://github.com/pillarjs/understanding-csrf, были заброшены и не ответили на новые вопросы и сомнения, подобные этому.

ПРОБЛЕМА

Допустим, у меня есть:

  • серверная часть на back.domain.com и
  • интерфейс на front.domain.com.

Моя серверная часть представляет собой простое приложение nodejs со следующими конечными точками:

  1. POST /login:

    1. accepts JSON body like: {"username": "myname", "password": "mypass"}
    2. проверить учетные данные
    3. если OK дает 200 и создает куки с сеансом
    4. если НЕ дает 401

  2. GET /players:

    1. check session in cookie
    2. если OK дает 200 с {"players": "[...]"}
    3. если НЕ дает 401

  3. POST /player/1:

    1. check session in cookie
    2. если OK дает 200 и редактирует игрока
    3. если НЕ дает 401

Мое внешнее приложение имеет:

  1. /login страница с формой (с полями username и password) для оформления POST запроса к back.domain.com/login

  2. /players которые запрашивают GET запрос к back.domain.com/players

  3. кнопка, которая отправляет POST запрос back.domain.com/player/1

ВОПРОСЫ

  1. Нужна ли мне защита от CSRF в этом сценарии?

    Я думаю ДА, мне нужно, потому что злоумышленник может отправить запрос к back.domain.com/player/1 из malicious.site.com и использовать мой файл cookie сеанса для редактирования игрока, потому что я вошел в систему (и у меня все еще есть файл cookie сеанса) на моем domain.com .

  2. Нужна ли мне защита от CSRF (например, заголовок X-CSRF-Token) при первом входе в систему back.domain.com/login?

    1. In this scenario I still don't have any session cookie in my browser.
    2. А также я не знаю, где взять мой CSRF-токен для заголовка авторизации X-CSRF-Token.

    Я читал на https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model они создают специальную конечную точку на сервере для этого и они объясняют это не уязвимость безопасности.

О чем вы думаете?


authentication rest csrf csrf-token
person Fred Hors    schedule 29.09.2019    source источник
comment
Я не могу ответить на вопрос, но у меня есть похожий сценарий, и я хотел бы знать, есть ли у вас какие-либо новые идеи.   -  person tg24    schedule 16.01.2020

Ответы (1)


arrow_upward
1
arrow_downward

Ты прав.

Вам ДЕЙСТВИТЕЛЬНО нужна защита от CSRF каждый раз, когда выполняются ОБА из следующих утверждений:

  • браузер автоматически предоставляет механизм аутентификации (чаще всего это делается с помощью файла cookie)
  • операция меняет состояние на вашем бэкэнде

Из трех ваших конечных точек только одна соответствует обоим этим условиям.

GET /players/: get не является операцией изменения состояния. Защита от CSRF не требуется.

POST /player/1/: аутентификация обеспечивается файлом cookie; пост меняет состояние. Нужна защита от CSRF!

POST /login/: браузер не предоставляет информацию для аутентификации автоматически; это происходит из данных, которые пользователь намеренно ввел и отправил. Защита от CSRF не требуется.

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

person Daniel Smedema    schedule 31.03.2020