Злоупотребление функцией Forgot_password

Внести вклад Функция
1

У меня есть пользователь, которого кто-то или скрипт атакует, многократно обращаясь к конечной точке forgot_password с его адресом электронной почты в течение дня. Это происходит уже несколько дней. Поскольку при этом отправляются письма, это также может создавать злоупотребления для системы. Из лога доступа nginx я отслеживал IP-адрес для части этого времени до другого пользователя в системе и отправил предупреждающее сообщение, но это может не помочь. Я также добавил этот IP-адрес в раздел Администрирование > Журналы > Отфильтрованные IP-адреса; однако я не уверен, что это сделает, кроме как временно заблокировать вход. IP-адрес может меняться и уже менялся, и, вероятно, он динамический, но также кто-то может включить VPN и начать всё заново.

У кого-нибудь есть предложение, как с этим справиться?

2 лайка
2020: The Year in Review
2

Привет, Дэн, если не возражаешь, сначала пара вопросов.

  1. Вы заблокировали этого пользователя?
  2. Разрешаете ли вы создание аккаунтов всем подряд или утверждаете все новые аккаунты вручную?

Чтобы заблокировать пользователя, перейдите по адресу admin/users/list/active и нажмите на имя нарушителя. На странице с его/её информацией прокрутите вниз до раздела Разрешения и нажмите Заблокировать. Убедитесь, что пользователь вышел из системы, так как блокировка может вступить в силу только после этого. Если он всё ещё в сети, в правом верхнем углу этой же страницы есть синяя кнопка для принудительного выхода из аккаунта. После выхода пользователь не сможет войти снова с помощью старых учётных данных.

Если вы утверждаете новые аккаунты — и «виновник» продолжает свои нарушения (и вы точно знаете, кто это) — пользователю придётся ждать, пока вы утвердите его аккаунт. Поскольку у вас уже есть один (или несколько?) IP-адресов, которые он использовал, если появится новый пользователь с этим IP, вы будете знать, что делать. :wink:
Также вы можете зайти в настройки пользователя, в раздел Аккаунт, и просмотреть недавно использованные устройства, где должны быть указаны IP-адреса, с которых он входил. Это может дать вам дополнительные IP для проверки.

Вот здесь и пригодится ручное утверждение аккаунтов.

:thinking: Как вообще этот человек получил доступ к профилю другого пользователя, чтобы запросить сброс пароля? Вот в чём главный вопрос.

2 лайка
3

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

2 лайка
6

Сколько именно раз в день?

2 лайка
7

Хорошо, «много» — понятие относительное.

root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log
214
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.1
147
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.2.gz
181
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.3.gz
140
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.4.gz
134
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.5.gz
251
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.6.gz
110
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.7.gz
100
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.8.gz
gzip: access.log.8.gz: No such file or directory
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.9.gz 
1
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.10.gz 
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.11.gz 
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.12.gz 
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.13.gz 
0
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.14.gz 
0

Очевидно, что этот поиск не отсеивает легитимные запросы. Я вручную проверил логи за сегодня и вчера и обнаружил несколько легитимных запросов (не с повторяющегося IP-адреса). Подавляющее большинство запросов исходит с повторяющегося IP-адреса, который меняется каждые несколько дней. Для системы это не очень серьёзно, но для получателя — неприятно. Думаю, единственное, что я могу сделать, — это настроить nginx на блокировку по IP-адресу, но поскольку он постоянно меняется… Возможно, если я буду проверять и обновлять список вручную в течение недели или двух, человек прекратит попытки, но, скорее всего, лишь на короткое время. Пострадавший говорит, что это впервые произошло с ним примерно 1,5 года назад.

3 лайка
8

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

По-моему, у нас здесь стоит ограничение по частоте запросов — порядка нескольких раз в минуту. Можете проверить этот участок кода @riking и подтвердить, что он всё ещё работает? Мы могли бы увеличить лимит, но это не сможет надёжно покрыть сценарий «несколько раз в день».

Кроме того, блокировка IP-адреса через Администрирование → Журналы → Заблокированные IP-адреса, полагаю, должна предотвращать отправку запросов на сброс пароля с этого адреса. Также стоит проверить, что это работает как положено @riking.

10 лайков
9

Это я получаю спам с поддельными запросами.
Это происходит несколько раз в час.

2020-05-07_00-53-12
2020-05-07_00-53-12957×620 42.6 KB

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

Некоторые сайты, которые я посещал, показывают ваш IP-адрес ещё до того, как вы запросите сброс пароля, сообщая, что он будет отправлен на вашу электронную почту.

Всё это очень небольшая досада, так как я редко проверяю эту почту для чего-либо. Все письма фильтруются и помечаются как «прочитанные», чтобы не создавалось впечатления, что их нужно читать. Я настроил фильтр в январе и сегодня впервые заглянул в эту папку (метку в Gmail).

3 лайка
10

Изображение, которое я не смог включить в первый ответ.
Когда Gmail получает несколько сообщений с одинаковой темой, он группирует их.
Полагаю, что после 100 одинаковых сообщений он переходит к следующей сотне.

chrome_2020-05-07_00-55-43
chrome_2020-05-07_00-55-43961×700 88.7 KB

5 лайков
11

Хорошая информация. Давайте завтра добьемся прогресса по этому вопросу @riking

6 лайков
12

У вас есть простое решение: измените ваш email с test@gmail.com на test+ТАЙНАКОТОРУЮЗНАЕТЕТОЛЬКОВЫ@gmail.com.

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

Я думаю, что на практике это лучшее, что можно сделать в данном случае.

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

12 лайков
13

Мы можем ограничивать частоту запросов для конкретного пользователя в дополнение к ограничению запросов из определённого места (ограничение, которое сейчас работает довольно эффективно). Может быть, выдавать людям до 2 неистёкших токенов сброса, прежде чем сказать: «просто подождите письмо на электронную почту»?

6 лайков
14

Другой подход — ограничить время действия писем для сброса пароля, например, до 3 часов между токенами. Если запрос на отправку письма для сброса пароля поступит до истечения периода ожидания, можно отобразить простое сообщение: «Мы уже отправили письмо для сброса пароля, пожалуйста, проверьте ваш почтовый ящик. Если письмо не придет в течение следующих 2 часов, обратитесь за помощью к администратору сайта по адресу %contact_email%».

2 лайка
15

Я изменил адрес электронной почты на форуме на формат ‘email+что-то@gmail.com’ и протестировал это в режиме инкогнито в другом браузере. Успех всё равно был достигнут. Возможно, потому что запрос всегда отправляется только с именем пользователя, а не с реальным адресом электронной почты.

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

Если бы была опция вопроса безопасности (которую можно активировать на уровне пользователя), я уверен, что это значительно сократило бы количество запросов, так как тролль просто не знал бы правильный ответ. Например: «Какой ваш любимый фильм?» или «Любимый ресторан».

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

3 лайка
16

Кажется, проблема в том, что можно просто собрать список пользователей форума и затем устроить шторм запросов «Забыли пароль».

Может, добавим режим, где для использования функции «Забыли пароль» нужно ввести email в точности? «Строгий режим» для «Забыли пароль» — по умолчанию выключен?

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

11 лайков
17

Есть ли способ предложить один или два «бесплатных» сброса сначала, прежде чем потребовать точного ввода, в течение определённого времени? Или, возможно, добавлять требование точного ввода только для отдельного аккаунта после нескольких попыток сброса, но автоматически в глобальном масштабе? :thinking:

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

:crossed_fingers: @Chinaski, надеюсь, что для вас это будет решено быстро и окончательно.

8 лайков
22

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

2 лайка
23

При тысячах активных пользователей (мы всё ещё находимся в процессе миграции на Discourse) я прекрасно понимаю вашу боль. Это происходит так часто — люди забывают, какой адрес электронной почты они использовали, и так далее. За последние годы это стало одним из самых частых запросов в службу поддержки, это просто безумие.

2 лайка
25

Требование ввода электронной почты при восстановлении пароля никогда не станет функцией по умолчанию.

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

5 лайков
28

Согласно

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

Также, следуя совету @riking, мы теперь учитываем фильтрованные адреса электронной почты: если администратор заблокирует IP-адрес, этот IP больше не сможет участвовать в этом «празднике».

Одно важное упущение здесь, @riking, которое могло бы немного помочь в самостоятельной борьбе с проблемой, заключается в том, что письмо «Сброс пароля» не содержит IP-адреса лица, инициировавшего запрос:

image
image1063×364 46.8 KB

@codinghorror, что вы думаете о добавлении IP-адреса инициатора в письма для сброса пароля (мы даже можем его немного скрыть)? Это позволит значительно улучшить самостоятельную борьбу с проблемой.

Джейн подвергается атаке
Джейн сообщает администратору сайта, что IP 12.12.12.12 постоянно сбрасывает пароли
Администратор блокирует IP 12.12.12.12

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

Facebook использует этот трюк, который я в целом поддерживаю внедрить:

image
image904×223 11.1 KB

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

Для контекста: Facebook требует электронную почту для сброса пароля (у них даже нет традиционного сброса пароля — это просто вход через электронную почту).

10 лайков
34

Я проанализировал 100 поддельных запросов и обнаружил закономерность, возможно, связанную с использованием скрипта. Эта закономерность прослеживается во всех 100 поддельных запросах в одной группе в Gmail.

NoteTab_2020-05-08_12-34-36
NoteTab_2020-05-08_12-34-36198×506 3.37 KB

3 лайка