# Уязвимость перебора email в диалоге «Сброс пароля»

**URL:** <https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449>\
**Category:** UX\
**Created:** [01.Август.2023 07:37:41 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449 "2023-08-01T07:37:41Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![dobon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/dobon/32/45119_2.png) [@dobon](https://meta.discourse.org/u/dobon)\
**Post date:** [04.Август.2023 04:27:36 UTC](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449/13 "2023-08-04T04:27:36Z")

</div>

Спасибо всем за ваши ценные отзывы и мнения по поводу этой уязвимости. Для меня ситуация предельно ясна и не представляет никакой сложности: в Discourse существует известная уязвимость, о которой неоднократно сообщали администраторы и специалисты по безопасности, такие как я, но её рассматривают как особенность, а не как уязвимость безопасности: [NIST: CWE-200: Раскрытие конфиденциальной информации неавторизованному лицу](https://cwe.mitre.org/data/definitions/200.html).

Обосновывать эту небезопасную конфигурацию по умолчанию, нарушающую общепринятые отраслевые стандарты, ссылаясь на гипотетическую ситуацию, когда администратор форума завален запросами пользователей о том, какие адреса электронной почты они использовали при регистрации, не имеет смысла. Дело в том, что использование страницы «Забыли пароль» не требует взаимодействия с администратором независимо от настроек этого параметра: если включена более безопасная и соответствующая стандартам настройка, пользователь просто проверит свои электронные письма в диалоге «Забыли электронную почту» и увидит, приходило ли на этот адрес письмо для сброса пароля, точно так же, как объясняется в самом диалоге, и как это реализовано во всех современных, уважающих конфиденциальность и соответствующих стандартам веб-приложениях. Кроме того, оправдание этого нарушения на основании того, что другие сайты _тоже могут нарушать лучшие практики_, не является логичным или убедительным аргументом с точки зрения безопасности и защиты данных. Мне трудно понять, почему мы предоставляем администраторам «возможность» делать установку Discourse чуть менее безопасной и менее соответствующей стандартам без какой-либо явной выгоды.

Тем не менее, я выполнил предписанную вами работу, @sam:

1. **Google** : _не_ допускает перебор пользователей.
2. **YouTube** : _не_ допускает перебор пользователей (поскольку использует вход через Google, а Google не допускает перебор пользователей).
3. **Facebook** : официально допускает перебор пользователей через страницу «Найти аккаунт»/«Забыли пароль» _только если пользователь специально пометил свой адрес электронной почты или номер телефона как публичные_, и [тем не менее печально известен утечкой данных 500 млн пользователей через уязвимость такого типа](https://www.wired.com/story/facebook-data-leak-contact-import-flaws/), а также [выплатил тысячи долларов специалистам по безопасности, которые обнаружили, что внутренние правила ограничения частоты запросов и «только если явно помечено как публичное» не соблюдались](https://www.websecgeeks.com/2014/02/facebook-user-enumeration-vulnerability.html).
4. **Instagram** : допускает перебор пользователей ([и пострадал из-за этого](https://www.arneswinnen.net/2016/05/instabrute-two-ways-to-brute-force-instagram-account-credentials/)). Это другой тип взлома, чем тот, о котором я упоминал для Facebook.
5. **X _(пожалуйста, проявляйте уважение и не используйте мёртвые имена на этом форуме)_**: допускает перебор пользователей через страницу сброса пароля, но реализует ограничение частоты запросов и несколько других [легко обходимых препятствий](https://int0x33.medium.com/day-9-osint-twitter-phone-enumeration-4b8ed782857d), а также [печально известен компрометацией телефонных номеров пользователей из-за ошибки в реализации ограничений частоты запросов и защиты данных](https://www.ghacks.net/2022/08/08/twitter-confirms-that-a-data-breach-leaked-email-addresses-and-phone-numbers-of-users/).
6. **Baidu** : допускает перебор пользователей на странице «Забыли электронную почту» и реализует капчу (и, возможно, ограничение частоты запросов? Мой китайский язык не очень хорош). Интересно, что процесс восстановления требует подачи апелляции в административную команду, а не просто отправки письма для восстановления. Очень типично для централизованного контроля КПК.
7. **Википедия** : _не_ допускает перебор пользователей.
8. **Yahoo** : допускает перебор пользователей через страницу сброса пароля, но реализует ограничение частоты запросов и капчу. Я не смог найти примеров того, что Yahoo попадала в скандалы или выплачивала хакерам за эксплуатацию этой уязвимости, но найти информацию о Yahoo в любом поисковике по понятным причинам очень сложно.
9. **Yandex** : допускает перебор пользователей на странице входа, реализует капчу и контрольный вопрос на странице «Забыли электронную почту».
10. **Whatsapp** : _не_ допускает перебор пользователей. Вход с ПК осуществляется через мобильные учётные данные. Мобильные учётные данные привязаны к номеру телефона. Кнопки выхода нет, равно как и страницы входа/страницы «Забыли электронную почту».
11. **XVideos** : _не_ допускает перебор пользователей.
12. **PornHub** : _не_ допускает перебор пользователей.
13. **Amazon _(сайт электронной коммерции)_**: [допускает перебор пользователей через страницу сброса пароля](https://samsclass.info/129S/proj/amp.htm), что является прямым нарушением [их собственных рекомендаций по лучшим практикам для продукта Cognito user pools в Amazon Web Services](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-managing-errors.html). Я не смог найти примеров того, что Amazon попадала в скандалы или выплачивала хакерам за эксплуатацию этой уязвимости, но найти информацию об Amazon в любом поисковике по понятным причинам очень сложно.
14. **Xnxx** : _не_ допускает перебор пользователей. На основном сайте нет страницы входа, а сайт «gold» не допускает перебор пользователей. Я нашел неработающую страницу входа в мобильной версии обычного сайта, и в ней просто отсутствует функциональность «Забыли электронную почту» (и, как выяснилось, она также устарела в пользу их сайта «gold»).
15. **Tik Tok** : _не_ допускает перебор пользователей. Принудительно требует многофакторную аутентификацию на странице сброса пароля.  
(21. **Reddit** : _не_ допускает перебор пользователей. Они соответствуют общепринятым отраслевым лучшим практикам.)

Из 15 лучших сайтов в этом списке 8 из 15 _не_ допускают перебор пользователей (или 9 из 16, если включить Reddit, и можно добавить 0,5 для Facebook, поскольку он позволяет перебор только информации, которую пользователь сознательно разрешил сделать публичной), и по крайней мере 3 из 7 сайтов из этого списка, которые _допускают_ перебор пользователей, столкнулись с критическими инцидентами безопасности именно из-за этого решения.

---

_[View the full topic](https://meta.discourse.org/t/email-enumeration-vulnerability-on-password-reset-dialogue/273449)._
