Одной из проблем, которая возникает для WEB-ресурсов, имеющих личные кабинеты, является атака методом перебора.
Да, простой поиск всех вариантов пароля для конкретной учетной записи.
Глупый? Возможно, но такая атака может сильно нагрузить ресурс.
Кроме того, если при регистрации не осуществляется контроль сложности пароля пользователя, она все равно может пройти успешно.
Чаще всего вопрос решается относительно просто.
Если пользователь несколько раз вводит неправильный пароль, его аккаунт блокируется на некоторое время.
Альтернативное решение — отображение капчи.
Сразу или после нескольких неудачных попыток.
Ну и не забудем про 2F авторизацию, которая практически неуязвима.
Казалось бы – прибыль! Но не все так радужно.
Давайте посмотрим на некоторые проблемы с описанными решениями: Временная блокировка — учетная запись пользователя временно заблокирована и он не может войти в систему.
Реальный пользователь испытывает душевную боль и мучения во время атаки.
Он не может войти в систему.
И, скорее всего, это создает нагрузку на вашу поддержку.
И самое интересное, что, возможно, это и есть цель нападающего.
Капча - относительно хорошее и эффективное решение.
Правда в том, что это доставляет неудобства пользователю, требуя от него ввести что-то дополнительное.
Довольно «неприятно» интегрироваться в дизайн.
Ах да.
эта штука, в зависимости от реализации, может подвергаться DoS-атаке.
2F авторизация - Все отлично.
Правда.
чаще всего это необязательная вещь.
Включить его для противодействия атаке не получится.
Она либо есть, либо ее нет. А на некоторых ресурсах ввести авторизацию 2Ф, скажем по воробьям из танка пострелять.
Я стараюсь создавать удобные и надежные сервисы.
Поэтому я решил немного поломать голову.
И вот что произошло.
Если вы пользуетесь почтой, например mail.ru, и у вас установлена 2F авторизация, то вы уже могли заметить, что 2F авторизация запрашивается только для нового «устройства» при первом входе.
Далее устройство считается доверенным.
И вам просто нужно ввести свое имя пользователя и пароль.
Удобная вещь.
Удобство для пользователя, так сказать.
Это реализуется двумя токенами.
Первый — это идентификатор «устройства» (мы определим его как devid), а второй — идентификатор сеанса (мы определим его как session).
Дэвид, в отличие от сессии, не теряет своей актуальности даже после того, как пользователь завершает сессию.
Он передается при следующем входе в систему, и если логин/пароль верны и девид доверенный, 2F больше не запрашивается.
Но если следующая попытка входа окажется неудачной, срок действия токена devid немедленно истечет. И теперь вам нужно пройти полный путь авторизации.
Эта парадигма была взята за основу.
Те.
ввести devid-токен, который будет выдаваться постоянно при любом ответе от WEB-ресурса, конечно, если его не было в запросе.
Для случая 2F авторизации фактически был реализован приведенный выше алгоритм.
И сразу все стали счастливы.
Вкл.
Подробно рассматривать нет смысла.
Но лучше посмотреть «навороты» на схеме, с пояснениями: 
Даже если 2F авторизация не установлена, но вход прошел успешно, токен devid помечается как доверенный.
Казалось бы, без авторизации 2F смысла это делать мало.
Но все немного сложнее.
Если мы знаем, что devid является доверенным, т.е.
с него был успешный вход в систему, мы как минимум предполагаем, что именно с этого устройства заходил реальный пользователь.
Это очень важная информация, которую описываемый алгоритм использует в своей работе в режиме об отражении нападения.
Была принята стратегия: любая авторизация может произойти только при наличии действующего devid-токена.
Валидный девид отличается от доверенного тем, что он еще НЕ является доверенным, т.е.
с него не было успешных входов в систему, но система готова обрабатывать запросы авторизации с его помощью.
Количество попыток на один действительный токен ограничено N раз.
Если ошибка авторизации возникает более N раз подряд, токен помечается как «скомпрометированный».
Переносится в отдельный журнал со статистикой отбора.
Запросы с его участием продолжают обрабатываться, но.
залогиниться с ним уже невозможно.
Все, что происходит, — это накопление статистики активности.
Так отражаются самые глупые атаки.
Например, если злоумышленник, игнорируя devid, попытается войти в систему, или если он не сможет понять логику devid (откуда он узнает, сколько попыток входа дается с тем же devid?), его запросы прекращаются.
Собственный фронт знает, что после N раз неудачных попыток входа с одного девида он уже «гнилой».
Теперь вам необходимо получить новый токен перед следующей попыткой входа в систему.
Казалось бы, что за глупость? Отрабатывать попытки входа спереди.
но, как я говорил выше, всё хитрее.
Если пользователь работает через обычный фронт, вероятность того, что он действительно пытается атаковать систему, незначительна.
В сочетании с системой контроля сложности пароля при регистрации пользователя это совершенно бесполезно.
Скорее всего, реальный пользователь действительно пытается вспомнить свой пароль.
Ну и в чем фокус? Дело в том, что на бэкенде мы генерируем те самые валидные деледы с определённым лимитом времени.
Например, не более 1000 штук в минуту.
Если вдруг этот предел будет превышен, активируется режим атаки.
И здесь можно либо пойти радикально и на какое-то время прекратить выдачу дедидов, что резко охладит пыл злоумышленника, либо уменьшить объемы генерации валидных дедидов.
Или вы можете включить одну и ту же проверку для всех действительных, но ненадежных девидов.
Это создает гибкую систему мониторинга и управления атаками.
Формируются достоверные метрики, по которым можно запустить мониторинг, подняв тревогу.
Накопленную статистику можно конвертировать в правила блокировки и т.д. А система дружелюбна тем, что те пользователи, которые ранее в нее заходили, т. е.
имели доверенных девидов, даже не заметят атаку.
Они будут пропущены через систему без проблем.
Теперь вот прибыль.
Этот алгоритм очень хорошо зарекомендовал себя на ресурсах с очень высокой нагрузкой.
Были, помимо прочего, попытки DoS и самого алгоритма, но и здесь он показал себя достойно.
Теги: #информационная безопасность #Алгоритмы #браузеры #безопасность #грубая атака
-
Веб-Сайт Wordpress Для Малого Бизнеса
19 Oct, 24 -
Искусство Управления Ит-Проектами, 2-Е Изд.
19 Oct, 24 -
Мое Путешествие В Будущее
19 Oct, 24 -
Провал Gpl
19 Oct, 24 -
Когда Выгнать Сисадмина
19 Oct, 24
