В приложении учётная запись блокируется после нескольких неудачных входов. Как проверить, что эту защиту нельзя использовать для блокировки чужого пользователя?
Нужно проверить, может ли неавторизованный человек, зная идентификатор пользователя, вызвать его блокировку серией неудачных входов. Защита должна сдерживать перебор паролей, но не позволять легко превратить имя пользователя в точку отказа в обслуживании.
Блокировка учётной записи появилась как противодействие автоматическому подбору паролей через онлайн-форму входа. Ограничение числа попыток повышает стоимость перебора, однако жёсткая постоянная блокировка создаёт новый риск: злоумышленник может намеренно исчерпать лимит для выбранной жертвы.
Поэтому современные схемы обычно сочетают несколько механизмов: задержки между попытками, ограничение частоты запросов, временные блокировки, дополнительные проверки риска и уведомления. Это позволяет уменьшить вероятность перебора без чрезмерного ухудшения доступности легитимных пользователей.
Тестировщик создаёт контролируемую учётную запись и выполняет неудачные попытки входа, указывая её идентификатор. Затем проверяется, становится ли невозможен корректный вход и как долго действует ограничение.
Важно повторить проверку с разных IP-адресов, устройств и параллельных сессий. Если счётчик связан только с IP-адресом, распределённый перебор может обходить защиту; если он связан только с учётной записью, любой внешний пользователь может заблокировать именно её.
Неверное решение может привести к отказу в обслуживании, раскрытию существования учётных записей через различия в ответах или чрезмерным блокировкам пользователей за ошибочные вводы пароля.
Проверка должна установить, где ведётся счётчик неудачных попыток, когда он сбрасывается и какие события вызывают блокировку. Нужно отдельно проверить неудачные попытки для существующего и несуществующего имени, успешный вход между ошибками, параллельные запросы, истечение времени блокировки и восстановление доступа.
Безопаснее, когда вместо немедленной бессрочной блокировки применяются прогрессивная задержка, ограничение частоты и временное замедление подозрительных запросов. Если временная блокировка всё же используется, её срок должен быть ограниченным, а восстановление — защищённым от обхода и не должно полагаться только на легко угадываемые контрольные вопросы.
Ограничение следует оценивать по нескольким признакам: учётная запись, источник запроса, устройство, сетевой диапазон и поведенческий контекст. Ни один отдельный признак не идеален: общий прокси может ошибочно затронуть многих пользователей, а распределённая атака обойдёт ограничение по одному адресу.
Тестировщик также проверяет, не раскрывает ли приложение состояние учётной записи разными сообщениями, кодами ответа или временем обработки. Логи и оповещения должны фиксировать подозрительные серии попыток, но не содержать пароли и другие секреты.
В корпоративном портале после пяти ошибок входа аккаунт блокировался на 30 минут. Проверка показала, что блокировка рассчитывалась только по имени пользователя: отправив пять неверных запросов с одного адреса, можно было сделать недоступной учётную запись любого сотрудника.
Рассматривались три варианта. Полностью убрать блокировку было просто, но это существенно облегчало онлайн-перебор. Увеличить порог снижало число случайных блокировок, однако не устраняло саму атаку. Ограничение только по IP не помогало против распределённых запросов и могло затронуть пользователей за общим прокси.
Выбранное решение объединило ограничение частоты по учётной записи и источнику, возрастающую задержку, короткие временные ограничения для явно подозрительных серий и уведомление пользователя о попытках входа. В результате перебор стал существенно менее эффективным, а возможность мгновенно заблокировать конкретного сотрудника исчезла; параметры дополнительно проверили нагрузочным тестом и на сценариях с общим сетевым адресом.
Нет. Атакующий может распределить запросы по множеству адресов, а несколько легитимных пользователей могут находиться за одним NAT или корпоративным прокси. Ограничение по IP полезно как один из сигналов, но должно сочетаться с ограничениями по учётной записи и контексту запроса.
Нужно сравнить веб-вход, мобильный клиент, API, восстановление пароля и другие доступные механизмы аутентификации. Если каждый канал ведёт независимый счётчик, атакующий может распределять попытки между ними. При этом объединение счётчиков должно быть реализовано аккуратно, чтобы сбой одного механизма не блокировал все легитимные способы доступа.
Такая схема хорошо останавливает перебор, но превращает любой известный идентификатор пользователя в средство отказа в обслуживании и создаёт значительные операционные расходы. Если бессрочное ограничение необходимо для высокорисковых сценариев, требуется отдельный защищённый процесс восстановления, уведомление владельца и контроль злоупотреблений; для обычного входа чаще предпочтительны временные ограничения и адаптивные меры.