Ответ 1

Нет, для этой конкретной ситуации нет. Атака CSRF позволяет злоумышленнику использовать права, которые имеет жертва, например bank.com/pay?ammount=1000&to=34.67.978.246

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

Причина, по которой Rails использует защиту CSRF в поле входа, проста: гораздо проще реализовать защиту CSRF во всем мире, чем 95% полей;)

Ответ 2

На CSRF

Во-первых, нужно прояснить, что такое CSRF.

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

Рассмотрим следующий пример: хакер знает, что у вас есть учетная запись на www.example.com, и скажем, что веб-сайт, на который вы вошли, все еще работает действующий сеанс. Теперь хакер может заманить вас к открытию другого веб-сайта, скажем trustme.com, на котором он разместил изображение со следующим кодом:

<img src="http://www.example.com/users/delete"/>

Если программисты www.example.com действительно сделали возможным удаление вашей учетной записи через этот URL с помощью простого запроса GET, и хакер знает, что простое просмотр и загрузка этого изображения с вашим действительным файлом cookie удалит вашу учетную запись на example.com, даже если вы работали только на trustme.com, и казалось, что эти два сайта не имеют ничего общего друг с другом.

Чтобы подвести итог этого примера, CSRF использует доверие, которое сайт имеет в браузере пользователя, в этом случае доверие, которое www.example.com имел в вашем браузере.

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

Таким образом, как правило, всякий раз, когда вы используете файлы cookie и сеансы для запросов на проверку пользователя, то есть для подтверждения или установления доверия к пользователю, используйте защиту CSRF. Так как вы хотите установить доверие к своему пользователю, когда он регистрируется, то же самое относится.

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

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

1. Хакер создает учетную запись на сайте, которому вы действительно доверяете (youtrustthis.com)
2. Он подделывает запрос на вход в ваш браузер со своими учетными данными и обманывает вас, используя свой аккаунт
3. Если вы не заметили, что вы на самом деле просматривали сайт youtrustthis.com как другой пользователь, злоумышленник позже увидит, что вы сделали "от его имени", что в значительной степени шпионит за вами.

2.: Без защиты CSRF хакер может имитировать ваш логин или форму регистрации в своем html-документе и удобно отправлять его снова и снова (или просто делать это, используя curl из терминала), при этом доверенный сайт не замечает, что запросы не на самом деле исходят из самого себя - то есть фактическая форма входа в доверенный домен никогда не отображалась в вашем браузере и не отправлялась оттуда. Это позволяет ему выполнять атаки грубой силы намного легче. Если злоумышленнику удастся выяснить учетные данные, ваш сервер ответит допустимым файлом cookie сеанса и доверится этому пользователю, с помощью которого он украл вашу личность. Если это форма регистрации, он сможет зарегистрировать огромное количество аккаунтов и тем самым спамить вашу базу данных.

Подводя итог этого: идти с защитой CSRF. Злонамеренный пользователь может очень часто использовать незащищенный вход в систему и подписывать формы, чтобы злоупотреблять вашим сайтом и шпионить за вашими пользователями или похищать их личности.

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

На потенциальных обходных путях

Поскольку защита CSRF использует сеансы для сравнения токена, сгенерированного на стороне сервера, с токеном, отправленным из формы, я не могу придумать способ сделать это только на стороне клиента, то есть без использования стека Rails. Все дело в том, что клиент получает токен только после того, как получает сгенерированную серверную часть.

Ответ 3

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

Более вероятный риск, вероятно, нетехнический. Когда ваш сайт получит аудит безопасности, вам придется объяснить, почему csrf здесь не риск... и доказать отрицательный результат сложно... "Appscan помечает это как критическое отверстие для безопасности - почему бы вам не исправить это? Почему у вас нет хорошего чистого отчета, такого как Чарльз?":)

Ответ 4

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

Там есть информация об этом в http://broadcastingadam.com/2011/05/advanced_caching_in_rails/ в заголовке "CSRF и form_authenticty_token". Соответствующий код:

$("meta[name='csrf-token']").attr('content', '<% Rack::Utils.escape_html(request_forgery_protection_token) %>');
$("meta[name='csrf-param']").attr('content', '<% Rack::Utils.escape_html(form_authenticity_token) %>');

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

Ответ 5

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

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

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

Ответ 6

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

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

• Первое: ты не хочешь этого допустить. Вы хотите владеть, откуда поступают запросы.
• Второе: ложные оповещения могут быть заблокированы.
• Третье: если вы разрешите авто вход в систему, зарегистрируйтесь так же уязвимо, как и форма входа в систему csrf