Это старый пост. Однако я подумал о том, чтобы разместить здесь свои выводы, чтобы они могли помочь любому будущему разработчику.
Нам необходимо предотвратить атаку методом "грубой силы", чтобы злоумышленник не смог получить имя пользователя и пароль для входа на веб-сайт. Во многих системах они имеют некоторые открытые URL-адреса, для которых не требуется токен аутентификации или ключ API для авторизации. Большинство из этих API являются критическими. Например; API для регистрации, входа в систему и забытого пароля часто открыты (т.е. не требует проверки токена аутентификации). Мы должны убедиться, что услуги не злоупотребляют. Как указывалось ранее, я просто размещаю свои выводы здесь, изучая, как мы можем эффективно предотвратить атаку грубой силой.
Большинство распространенных методов профилактики уже обсуждались в этом посте. Я хотел бы добавить свои опасения в отношении блокировки учетной записи и IP-адреса. Я думаю, что блокировка учетных записей - плохая идея как метод предотвращения. Я помещаю некоторые пункты здесь, чтобы поддержать мое дело.
блокировка аккаунта плохая
- Злоумышленник может вызвать отказ в обслуживании (DoS), заблокировав большое количество учетных записей.
- Поскольку вы не можете заблокировать учетную запись, которая не существует, блокируются только действительные имена учетных записей. Злоумышленник может использовать этот факт для сбора имен пользователей с сайта, в зависимости от ответов об ошибках.
- Злоумышленник может отвлечь внимание, заблокировав множество учетных записей и наполнив службу поддержки звонками в службу поддержки.
- Злоумышленник может постоянно блокировать одну и ту же учетную запись, даже через несколько секунд после того, как администратор разблокирует ее, эффективно отключая учетную запись.
- Блокировка учетной записи неэффективна против медленных атак, которые пытаются использовать только несколько паролей каждый час.
- Блокировка учетной записи неэффективна против атак, которые пытаются использовать один пароль для большого списка имен пользователей.
- Блокировка учетной записи неэффективна, если злоумышленник использует комбинированный список имени пользователя и пароля и правильно угадывает с первой пары попыток.
- Мощные учетные записи, такие как учетные записи администратора, часто обходят политику блокировки, но они являются наиболее желательными учетными записями для атаки. Некоторые системы блокируют учетные записи администратора только при сетевых входах в систему.
- Даже после того, как вы заблокируете учетную запись, атака может продолжаться, потребляя ценные человеческие и компьютерные ресурсы.
- Рассмотрим, например, сайт аукциона, на котором несколько участников сражаются за один и тот же предмет. Если на веб-сайте аукциона предусмотрена блокировка аккаунта, один участник может просто заблокировать аккаунты других в последнюю минуту аукциона, не давая им возможности подать любые выигрышные заявки. Злоумышленник может использовать ту же технику для блокировки критических финансовых транзакций или обмена электронной почтой.
Блокировка IP-адреса для учетной записи тоже плохая идея
Другим решением является блокировка IP-адреса с несколькими неудачными входами в систему. Проблема с этим решением состоит в том, что вы можете непреднамеренно заблокировать большие группы пользователей, заблокировав прокси-сервер, используемый поставщиком услуг Интернета или крупной компанией. Другая проблема заключается в том, что многие инструменты используют списки прокси-серверов и отправляют только несколько запросов с каждого IP-адреса, прежде чем перейти к следующему. Используя широко доступные списки открытых прокси на веб-сайтах, таких как http://tools.rosinstrument.com/proxy/,, злоумышленник может легко обойти любой механизм блокировки IP. Поскольку большинство сайтов не блокируются после одного неудачного пароля, злоумышленник может использовать две или три попытки для одного прокси. Злоумышленник со списком из 1000 прокси-серверов может попытаться заблокировать 2000 или 3000 паролей. Тем не менее, несмотря на недостатки этого метода, сайты, которые подвергаются большому количеству атак, в частности сайты для взрослых, предпочитают блокировать IP-адреса прокси.
Мое предложение
- Не блокировка учетной записи. Вместо этого мы могли бы рассмотреть возможность добавления преднамеренной задержки со стороны сервера при попытках входа / регистрации для последовательных неправильных попыток.
- Отслеживание местоположения пользователя по IP-адресу при попытках входа в систему, что является распространенным методом, используемым Google и Facebook. Google отправляет OTP, в то время как Facebook предоставляет другие проблемы безопасности, такие как обнаружение друзей пользователя по фотографиям.
- Google re-captcha для веб-приложения, SafetyNet для Android и соответствующая техника аттестации мобильных приложений для iOS - в запросах на вход в систему или регистрацию.
- Cookie устройства
- Создание системы мониторинга вызовов API для обнаружения необычных вызовов для определенной конечной точки API.
Объясненные предложения
Преднамеренная задержка ответа
Задержка аутентификации по паролю значительно замедляет атакующего, так как успех атаки зависит от времени. Простым решением является введение случайных пауз при проверке пароля. Добавление даже нескольких секунд паузы не будет беспокоить большинство законных пользователей, когда они входят в свои учетные записи.
Обратите внимание, что хотя добавление задержки может замедлить однопоточную атаку, она менее эффективна, если злоумышленник отправляет несколько одновременных запросов аутентификации.
Проблемы безопасности
Этот метод может быть описан как проблемы адаптивной безопасности, основанные на действиях, выполненных пользователем при использовании системы ранее. В случае нового пользователя этот метод может бросить вызов безопасности по умолчанию.
Мы могли бы рассмотреть вопрос о включении, когда мы будем бросать вызовы безопасности? Есть несколько моментов, где мы можем.
- Когда пользователь пытается войти в систему с того места, где его раньше не было.
- Неправильные попытки входа в систему.
С какой проблемой безопасности может столкнуться пользователь?
- Если пользователь задает вопросы безопасности, мы можем подумать о том, чтобы спросить у них ответы на них.
- Для таких приложений, как Whatsapp, Viber и т. Д. Мы могли бы рассмотреть возможность выбора случайных имен контактов из телефонной книги и попросить ввести их номера или наоборот.
- Для транзакционных систем мы могли бы рассмотреть вопрос о запросе пользователя о последних транзакциях и платежах.
Панель мониторинга API
Создание панели мониторинга для вызовов API.
- Ищите условия, которые могут указывать на грубую атаку или другое злоупотребление учетной записью в панели мониторинга API.
- Множество неудачных входов с одного IP-адреса.
- Вход в систему с несколькими именами пользователей с одного IP-адреса.
- Логины для одной учетной записи, поступающей с разных IP-адресов.
- Чрезмерное использование и потребление полосы пропускания от одного использования.
- Неудачные попытки входа в систему с алфавитно-последовательными именами пользователей или паролями.
- Логины с подозрительными паролями, которые обычно используют хакеры, такие как ownsyou (ownzyou), washere (wazhere), фанатики, hacksyou и т. Д.
Для внутренних системных учетных записей мы могли бы разрешить вход в систему только с определенных IP-адресов. Если требуется блокировка учетной записи, вместо полной блокировки учетной записи, переведите ее в режим блокировки с ограниченными возможностями.
Вот некоторые хорошие чтения.