Нужны ли в регистрационных формах токены против атак CSRF?

Из того, что я узнал до сих пор, цель жетонов состоит в том, чтобы предотвратить нападение злоумышленника на подачу формы.

Например, если на веб-сайте была форма, в которую вводились добавленные элементы в корзину, а злоумышленник мог бы спамить вашу корзину покупок, которые вам не нужны.

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

Я понимаю, как работают токены и добавляет безопасность в этом случае, потому что они гарантируют, что пользователь действительно заполнил и нажал кнопку «Отправить» формы для каждого элемента, добавленного в корзину.

Однако, делают ли токены добавлением какой-либо безопасности в форму входа пользователя, для которой требуется имя пользователя и пароль?

Так как имя пользователя и пароль очень уникальны, злоумышленник должен знать как для того, чтобы подделка входа в систему работала (даже если у вас не было настройки токенов), и если злоумышленник уже знал это, он мог просто войти на сайт сам. Не говоря уже о том, что атака CSRF, заставляющая пользователя войти в систему, в любом случае не имела бы никакой практической цели.

Является ли мое понимание CSRF-атак и токенов правильными? И они бесполезны для форм входа в систему, как я подозреваю?

Solutions Collecting From Web of "Нужны ли в регистрационных формах токены против атак CSRF?"

Да. В общем, вам необходимо защитить свои формы входа от атак CSRF так же, как и любые другие.

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

Уязвимость выглядит следующим образом:

  1. Злоумышленник создает учетную запись хоста в доверенном домене
  2. Злоумышленник подделывает запрос на вход в браузере жертвы с учетными данными этой учетной записи хоста
  3. Злоумышленник обманывает жертву в использовании доверенного сайта, где они могут не заметить, что они вошли в систему через учетную запись хоста
  4. Теперь злоумышленник имеет доступ к любым данным или метаданным, которые жертва «создала» (намеренно или непреднамеренно), в то время как их браузер был зарегистрирован с учетной записью хоста

В качестве подходящего примера рассмотрим YouTube . YouTube разрешил пользователям видеть запись «собственной» истории просмотров, а их форма входа была CSRF-уязвимой! Таким образом, злоумышленник мог настроить учетную запись с помощью пароля, который они знали, зарегистрировать жертву на YouTube с помощью этой учетной записи – преследовать видео, которые наблюдал жертва.

В этой ветке комментариев есть обсуждение, которое подразумевает, что оно может «использоваться» только для нарушений конфиденциальности. Возможно, но процитировать раздел в статье CSRF Википедии :

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

Акцент на «новые атаки». Представьте себе влияние фишинговой атаки на ваших пользователей, а затем представьте, что фишинг-атака работает через собственную доверенную закладку пользователя на ваш сайт! Документ, связанный в вышеупомянутой ветке комментариев, дает несколько примеров, которые выходят за рамки простых атак на неприкосновенность частной жизни.

Ваше понимание верное – весь смысл CSRF заключается в том, что злоумышленник может заранее подготовить законный запрос. Но это невозможно сделать с формой входа, если злоумышленник не знает имя пользователя и пароль жертвы, и в этом случае есть более эффективные способы атаки (войдите самостоятельно).

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