Атаки на авторизацию. Часть 1: Вход по паролю

Я исследую веб‑безопасность и делюсь практическими разбориками уязвимостей: от CSRF и XXE до Server‑Side XSS, race conditions и обходов CSP. Пишу чек‑листы атак и защиты, редкие кейсы из практики и мысли о мышлении пентестера. Только прикладной AppSec, понятные примеры и то, что реально встречается в проде. Учимся охотиться, пока на нас не охотятся.

аутентификациябрутфорсusername enumeration

Решил сделать небольшой цикл постов по атакам на авторизацию. Чтобы не перегружать материалом - все поделено на части и оформлено подобно чеклисту, чтобы можно было удобно пользоваться и изучать.

Данный пост посвящен атакам на обычные формы авторизации логин-пароль, которые можно увидеть буквально везде. Тут стоит отметить, что доминирующая составляющая подобных атак - брутфорс (перебор).

🔷Тип: Web, Server-Side

  • Weak/Default Password Guessing - простейшие комбинации вида admin:admin и пароли по умолчанию для систем (postgres:postgres) легко гуглятся и угадываются одним запросом
    • 🌞 Защита: Смена паролей по умолчанию и проверка сложности пароля
  • Credential Stuffing - переиспользование пар логин-пароль, "слитых" в открытых/закрытых источниках
    • 🌞 Защита: Регулярная смена паролей
  • Username Enumeration - возможность определить, зарегистрирован ли пользователь из-за разных ответов сервера (разные сообщения/коды ответа если введен существующий/несуществующий логин)
    • 🌞 Защита: Возвращение одинакового ответа вне зависимости от существования пользователя
    • ---- 🛡 Обход: Опечатки в сообщениях (лишний пробел/точка)
    • ---- 🛡 Обход: Разное время ответа в зависимости от существования/отсутствия пользователя (приложение дольше "думает")
  • Login/Password Bruteforce - перебор по спискам наиболее популярных логинов/паролей
    • 🌞 Защита: Блокировка по IP
    • ---- 🛡 Обход: Периодический вход в существующий аккаунт (сброс счетчика неверных попыток)
    • ---- 🛡 Обход: Маскировка реального IP (заголовками X-Forwarded-For и подобными)
    • ---- 🛡 Обход: Использование распределенной системы перебора
    • 🌞 Защита: Блокировка аккаунта
    • ---- 🛡 Создает User Enumeration (сообщение о том, что УЗ заблокирована позволяет понять, что она существует)
    • 🌞 Защита: CAPTCHA
    • ---- 🛡 Обход: Эксплуатация мисконфигураций CAPTCHA (переиспользование, модификация, игнорирование и пр.)
  • "Smart" Bruteforce - эксплуатация особенностей языков программирования, реализации и технологий
    • 🔫 Пример: Некоторыя ЯП (или плохие реализации) могут по-разному кастовать и десериализовать тип переменных, что может позволить вам вместо пароля отправить массив паролей, каждый из которых будет проверяться к логину
    • 🔫 Пример: Если для аутентификации используется GraphQL, он может позволить отправить несколько запросов на авторизацию одним запросом, используя алиасы
  • Bruteforce Basic Authorization - если приложением используется базовая авторизация, зачастую у него не будет никаких механизмов защиты от перебора, а сам механизм базовой авторизации себя защищать не умеет и легко реконструируется атакующим
    • 🌞 Защита: Отказаться от базовой авторизации (ну реально - не модно уже, еще и пароли ваши в открытом доступе летают - не солидно)
  • Other Vulnerability Types Exploitation - на данном этапе часто применимы прочие самостоятельные классы уязвимостей, такие как атаки на JWT, SQLi, NoSQLi, Race Conditions, SSTI и прочие. О них будут (или уже были) отдельные посты.
    • 🌞 Защита: уникальна для каждого отдельного класса уязвимостей

Также, в тепличных условиях иногда встречается такой зверь как Client-Side Authorization. Осознать причины, почему это является абсолютно небезопасным подходом я оставлю как упражнение читателю.

#edu #vuln #web #auth

Иллюстрация: ноутбук с полем для ввода пароля, крючок фишинга и визуальные метки атаки — метафора попытки взлома авторизации через перебор и фишинг
Иллюстрация попытки взлома пароля: визуальная метафора brute‑force и фишинга

Дискуссия

Ярослав Сырцев
А есть ли способ обезопасить авторизацию на клиенте?
Критика чистого разума (Hunt Or Be Hunted Chat)
Ярослав Сырцев
А есть ли способ обезопасить авторизацию на клиенте?
Фронт по факту это интерфейс для взаимодействия с беком. Если ты будешь понимать, как он тебе генерирует запрос - ты можешь отправить его без участия фронта (что соответственно обойдет все защиты клиентской стороны) Можно пытаться обфусцировать код, делать его сложным и непонятным, генерировать какие-то странные значения в странном формате - это все ненадолго задержит человека, но не остановит его полностью
Присоединиться к обсуждению →

Читайте так же