Нужны ли для входа формы токены против CSRF-атак?

161

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

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

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

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

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

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

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

php token csrf php_learner
источник
Они могут похитить ваш роутер, потому что вы, вероятно, используете пароль по умолчанию, и он не защищен CSRF для входа в систему.
AbiusX
Да, поэтому другие сайты не могут имитировать вашу форму входа. Чего они могут достичь, делая это? Сначала ты не хочешь этого допустить. Второе: очень простые случаи сбоев, такие как блокировка пользователя из-за неверного пароля n нет. раз, можно избежать.
Mayankcpdixit

Ответы:

126

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

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

Уязвимость выглядит так:

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

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

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

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

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

natevw
источник
6
Как помогает защита от CSRF? Что-то мешает злоумышленнику запросить свой собственный токен CSRF и просто отправить его с этим? Поскольку сеанса с проверкой подлинности не существует, у веб-сервера нет причин предпочитать один токен другому.
А. Уилсон
2
«Есть ли что-то, что мешает злоумышленнику запросить свой собственный токен CSRF и просто отправить его с этим?» - Да! Это целое предположение, лежащее в основе логики предотвращения CSRF. Браузеры делали / действительно разрешали отправку форм для нацеливания на другое происхождение, но они никогда [преднамеренно] не позволяли JS читать данные через сайты, кроме как теперь через opt-in CORS. Если вы не настроили CORS неправильно, злоумышленник может инициировать отправку формы (которая может включать в себя существующий токен CSRF в файлах cookie ), но не может узнать токен для отправки требуемой второй копии (например, в теле / ​​заголовках). Поэтому код CSRF будет отклонен.
natevw
7
Я думаю, что ваш последний комментарий неверен (вы неправильно поняли, что говорил А. Уилсон). Мы говорим, что злоумышленник может загрузить http://good.com/login.htmlв одном клиенте, проанализировать вложенный токен CSRF, а затем опубликовать http://bad.com/login.html, содержащую измененную форму, которая отправляет свое имя пользователя, пароль и токен независимо от того, что вводит жертва. CORS не применяется, потому что вы ' У нас есть два отдельных клиента: злоумышленник и жертва. Итак, еще раз повторю вопрос: действительно ли защита CSRF работает для форм входа в систему?
Гили
8
Да, CSRF защитит форму входа от подделки межсайтовых запросов . Правильный токен CSRF криптографически уникален каждый раз, когда он генерируется. Конечно, злоумышленник может получить токен самостоятельно, но он все равно НЕ СОГЛАСИТСЯ с [потенциально неустановленным] cookie-файлом, который жертва имеет в своем браузере, и у злоумышленника нет возможности установить указанный cookie-файл без ущерба для страницы в хорошем домене. (Ваш пример кажется немного запутанным между CSRF и какой-то странной фишинг-атакой, поэтому я не уверен, отвечаю ли я на ваш актуальный вопрос ...)
natevw
3
Я могу ошибаться, но, похоже, существует значительная угроза, если пользователь случайно делает что-либо, связанное с покупкой предметов. Например, злоумышленник обманом заставляет пользователя войти в систему на веб-сайте, а пользователь продолжает покупать товары, не осознавая, что они находятся в другой учетной записи (например, Amazon или аналогичная). Теперь злоумышленник имеет доступ к сохраненной информации о платеже, может перенаправить покупки и т. Д.
you786
14

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

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

Джон
источник
2
Ух Супер быстрый ответ! Большое спасибо! Теперь я могу уверенно продолжать строить свой сайт.
php_learner
21
Вход в CSRF все еще можно использовать для атак на конфиденциальность пользователя seclab.stanford.edu/websec/csrf/csrf.pdf
squiddle
6
@squiddle: Это довольно интересная статья, спасибо за ссылку. Но это зависит от входа пользователя в систему с учетной записью под контролем злоумышленника и предполагает, что пользователь не поймет, что что-то не так, и предполагает, что пользователь собирается выдавать конфиденциальную информацию, которая затем будет храниться на сервере. Так что ИМХО это гораздо менее серьезно, чем «классическая» CSRF.
Джон
6
@Jon Да, это может быть менее серьезно, но, в конце концов, это может быть больше, чем просто неудобство, а именно вторжение в личную жизнь. Каждый сервис должен сам определять свою модель угроз и обрабатывать ее соответствующим образом. Для этого нужно хотя бы быть в курсе возможных угроз. Вот почему я добавил свои 2 цента.
Squiddle
1
Пожалуйста, не могли бы вы рассказать о том, как они будут действовать: «В конечном счете, единственное, что может сделать злоумышленник, - это доставить неудобства вашим пользователям из-за нежелательных входов в систему, когда система безопасности может заблокировать пользователя на некоторое время».
samthebest
0

Да , поэтому другие сайты не могут имитировать вашу форму входа! Так просто, как, что.

Чего они могут достичь, делая это?

  • Первое: ты не хочешь этого допустить.
  • Второе: даже очень простые случаи отказа, такие как:
    • блокировка пользователя из-за неверного пароля n нет. раз, можно избежать.
    • Пламя оповещения о взломе может быть предотвращено. и т. д.
mayankcpdixit
источник
Большинство из этих пунктов неверны. Атакующий может создать форму входа в систему, получить учетные данные пользователя, загрузить форму входа в систему (с токеном csrf) и опубликовать три части информации для цели. CSRF не мешает этому.
Снейпий
Браузеры @Snapey обычно не позволяют JS читать данные CSRF. Используя JS, вы не можете имитировать подлинный запрос на отправку формы.
Mayankcpdixit
Токен csrf часто передается клиенту для использования в JavaScript. Я не говорю о cors, я говорю о злоумышленнике, просто запрашивающем форму входа и учетные данные. @mayankcpdxit. Похоже, вы подразумеваете, что csrf предотвращает заполнение учетных данных, а это не так.
Снейпий
Теоретически, да, это не может предотвратить. Но невозможно автоматизировать заполнение учетных данных после CSRF, если вы прекратите загрузку форм CSRF в iframes и перестанете разрешать требование перекрестного происхождения.
Mayankcpdixit
-1

Предварительная регистрация для проверки CSRF не имеет большого смысла ИМХО.

Спасибо @squiddle за ссылку: seclab.stanford.edu/websec/csrf/csrf.pdf , мы можем прочитать на самой первой странице:

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user’s session,
preventing CSRF by forcing the attacker to guess the
session’s token.

Если вы попытаетесь выполнить предварительную регистрацию в CSRF, вы дадите потенциальному злоумышленнику возможность удалить действительный код вашего веб-сайта! Затем он / она сможет повторно опубликовать токен, победив цель.

Возможно, злоумышленник может попытаться угадать имя пользователя вашего сайта. Что я сделал, если IP-адрес пытается угадать, скажем, 10 имен пользователей, но я просто попал в черный список.

Патрис Ганьон
источник