Волна фейковых регистраций: одноразовая почта, адреса «от имени» сервиса и бан, который не работал
Кейс из практики. Проект — финансовый онлайн-сервис с личными кабинетами, приёмом платежей, чатом поддержки и админ-панелью. Мы ведём его безопасность и инфраструктуру. Название проекта, адреса и даты не раскрываем; технические детали обобщены настолько, чтобы их нельзя было использовать для атаки.
Сначала это выглядело как спам: новые аккаунты на странные адреса. Потом заметили закономерность — регистрации шли каждые полторы минуты с одинаковыми заголовками, а часть адресов была на домене самого сервиса: «no-reply», «admin» и подобные.
Что происходило
- Первая волна — несколько аккаунтов с одного адреса: на домене сервиса, на бесплатной почте и на одноразовых ящиках.
- После блокировки адреса регистрации продолжились через прокси в разных странах — по одному одноразовому ящику каждые полторы минуты.
- С тех же аккаунтов шли запросы сброса пароля и сообщения в чат поддержки с HTML-вставками.
Зачем нужны фейковые аккаунты
| Цель | Как выглядит | Чем опасно |
|---|---|---|
| Доступ к функциям для зарегистрированных | Регистрация и сразу запросы к API кабинета | Расширяется поверхность атаки |
| Выдать себя за сервис | Адрес на домене сервиса | Сообщения от «официального» имени, фишинг сотрудников |
| Разведка сброса пароля | Много запросов восстановления | Перечисление клиентов, проверка токенов |
| Злоупотребление бонусами | Много аккаунтов на одного человека | Прямые финансовые потери |
Аккаунт с адресом на домене сервиса особенно неприятен: в админке и переписке он выглядит как сотрудник или системный ящик.
Бан, который не мешал войти
Мы пометили аккаунты первой волны как заблокированные — и увидели, что они продолжают получать токены. Флаг блокировки проверялся только при загрузке страниц личного кабинета, а обработчик входа проверял пароль и выдавал токен, не глядя на флаг. Бан действовал в интерфейсе, но не в API.
Что исправили
- Политика адресов. Отдельный модуль отклоняет адреса на домене сервиса и его поддоменах, а также домены одноразовой почты из поддерживаемого списка.
- Бан при входе. Вход заблокированного аккаунта возвращает 403, токен не выдаётся; проверка добавлена и в обновление сессии.
- Фильтр на уровне веб-сервера. Запросы к входу и регистрации с подписью бота отсекаются до приложения.
- Чистка. Все аккаунты волны заблокированы с указанием причины, адреса прокси внесены в чёрный список.
Чек-лист для регистрации
- Запретите регистрацию на собственный домен и домены сотрудников.
- Требуйте подтверждения почты до доступа к значимым функциям.
- Проверяйте блокировку при входе и в каждом защищённом API.
- Ограничьте частоту регистраций и сбросов пароля — с адреса и по сервису в целом.
- Отвечайте одинаково на «почта уже есть» и «письмо отправлено», чтобы нельзя было перечислить клиентов.
Материалы для проверки
Если нужна реализация
Состав работ зависит от текущего проекта и подтверждённой причины. Можно обсудить диагностику или разработку подходящего решения.
Вопросы и ответы
Стоит ли блокировать всю одноразовую почту?
Для финансовых сервисов и сервисов с бонусами — да. Для контентных сайтов хватает подтверждения почты и лимитов. Список доменов нужно регулярно обновлять.
Почему бан нужно проверять при входе, если кабинет и так закрыт?
API обычно доверяет токену. Если токен выдан, часть запросов пройдёт, даже когда интерфейс показывает «аккаунт заблокирован». Доступ перекрывают в точке выдачи токена.