🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 18.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
Страница входа — это первое, на что я обращаю внимание при тестировании любого веб-приложения.
На первый взгляд всё выглядит максимально просто: поле для имени пользователя, поле для пароля и кнопка «Войти». Но за этой простотой скрываются одни из самых распространённых и наиболее критичных уязвимостей в веб-безопасности.
За время работы я протестировал множество страниц авторизации. И каждый раз использую один и тот же чек-лист.
Ниже — список того, что я проверяю в первую очередь, и почему каждая из этих проверок действительно важна.
Почему страницы входа так интересны
Страница авторизации — это входная точка любого приложения.
Именно здесь происходит аутентификация пользователя — процесс подтверждения его личности. Если механизм аутентификации реализован с ошибками, злоумышленнику не придётся искать сложные или глубоко спрятанные уязвимости. Он сможет просто войти через «парадную дверь».
Именно поэтому страницы входа остаются одной из самых популярных целей для исследователей безопасности и участников программ Bug Bounty. Уязвимости здесь встречаются регулярно, их влияние на безопасность может быть крайне серьёзным, а обнаружить их можно даже в крупных и широко известных веб-приложениях.
Давайте разберёмся, что именно стоит проверять.
Проверка №1 — SQL-инъекция
Первое, что я всегда тестирую на любой форме входа, — это возможность SQL-инъекции.
SQL-инъекция возникает в случаях, когда пользовательский ввод передаётся в SQL-запрос без корректной обработки или параметризации. Если приложение недостаточно защищено, злоумышленник может изменить логику запроса и, например, обойти механизм аутентификации.
Что я проверяю
Я ввожу следующие тестовые нагрузки (payload) в поле имени пользователя или пароля:
' OR '1'='1 ' OR 1=1-- admin'-- ' OR 'x'='x
На что я обращаю внимание
- Удается ли войти в систему без действительных учетных данных?
- Возвращает ли приложение ошибку базы данных? (Сам по себе такой ответ уже является потенциальной уязвимостью.)
- Отличается ли поведение приложения при использовании подобных входных данных?
Почему это важно
Успешная SQL-инъекция на странице авторизации означает полный обход механизма аутентификации. В этом случае злоумышленник может войти под учетной записью любого пользователя, включая администратора, не зная ни одного пароля.
Проверка №2 — Учетные данные по умолчанию (Default Credentials)
Прежде чем переходить к более сложным методам, я всегда проверяю самые очевидные варианты.
Удивительно, но многие приложения — особенно внутренние корпоративные системы, административные панели и IoT-устройства — до сих пор используют стандартные логины и пароли, которые так и не были изменены после установки.
Что я проверяю
admin / admin admin / password admin / 123456 administrator / administrator root / root guest / guest
На что я обращаю внимание
Любая успешная авторизация.
Почему это важно
Использование учетных данных по умолчанию остается одной из самых распространенных и одновременно самых досадных ошибок в реальных системах. Такая проверка занимает меньше минуты, но иногда сразу предоставляет полный административный доступ.
Если вы тестируете административную панель, например расположенную по адресу /admin или /wp-admin, всегда начинайте именно с проверки стандартных учетных данных.
Проверка №3 — Защита от перебора паролей (Brute Force) и ограничение частоты запросов (Rate Limiting)
Могу ли я выполнить тысячи попыток входа подряд, не встретив никаких ограничений?
Rate Limiting — это механизм защиты, который ограничивает или замедляет повторные попытки авторизации. При его отсутствии злоумышленник может автоматически подбирать пароль до тех пор, пока не найдет правильный.
Что я проверяю
Я многократно пытаюсь войти с неверным паролем и наблюдаю за поведением приложения.
Проверяю:
- блокируется ли учетная запись после определенного количества неудачных попыток;
- появляется ли задержка между попытками входа;
- отображается ли CAPTCHA после серии ошибок;
- можно ли обойти защиту, изменив IP-адрес или подменив HTTP-заголовки.
Инструменты
Обычно использую Burp Suite (модули Intruder и Repeater) для многократной отправки одинаковых запросов и анализа ответов приложения.
Почему это важно
Если ограничение количества попыток отсутствует, злоумышленник может подбирать пароли с высокой скоростью. В сочетании с утекшим списком имен пользователей и популярными словарями паролей это часто приводит к компрометации большого количества учетных записей.
Проверка №4 — Перебор существующих имен пользователей (Username Enumeration)
Сообщает ли приложение о существовании указанного пользователя?
Username Enumeration возникает, когда приложение по-разному реагирует на существующие и несуществующие учетные записи. Это позволяет злоумышленнику заранее собрать список реальных пользователей, прежде чем приступать к подбору паролей.
Что я проверяю
Пытаюсь войти с использованием:
- существующего имени пользователя (например,
admin); - заведомо несуществующего пользователя (например,
xyzfakeuser123).
Затем сравниваю:
- текст сообщений — например, «Неверный пароль» и «Пользователь не найден» сразу выдают существующие учетные записи;
- время ответа — иногда проверка существующего пользователя занимает немного больше времени;
- HTTP-статусы — некоторые приложения возвращают разные коды ответа;
- страницу восстановления пароля — сообщения вроде «Письмо отправлено» и «Аккаунт не найден» являются классическим примером утечки информации.
Почему это важно
Если злоумышленник знает существующие имена пользователей, объем работы сокращается практически вдвое — остается подобрать только пароль.
Проверка №5 — Уязвимости механизма восстановления пароля
Функция «Забыли пароль?» — один из самых недооцененных и одновременно самых уязвимых компонентов системы авторизации.
Я всегда тестирую ее отдельно и максимально тщательно.
Что я проверяю
Слабые токены сброса пароля
Я проверяю, насколько случайными являются токены восстановления. Если используются короткие, последовательные значения или токены, основанные на времени (например, 12345), их можно подобрать.
Срок действия токена
Проверяю, перестает ли ссылка работать спустя разумное время. Если ссылка остается действительной через сутки после создания, это потенциальная уязвимость.
Повторное использование токена
После смены пароля пытаюсь повторно воспользоваться той же ссылкой восстановления. Если она продолжает работать, это ошибка безопасности.
Раскрытие информации о пользователях
Проверяю, различаются ли ответы системы:
- «Письмо отправлено»
- «Учетная запись не найдена»
Такая разница позволяет определить существование адресов электронной почты в системе.
Host Header Injection
Некоторые приложения формируют ссылку восстановления на основе HTTP-заголовка Host.
Если этот заголовок можно подменить, существует риск отправки пользователю ссылки, ведущей на сервер, контролируемый злоумышленником.
Почему это важно
Ошибки в механизме восстановления пароля позволяют захватить учетную запись без знания исходного пароля. Подобные уязвимости регулярно встречаются в программах Bug Bounty и зачастую относятся к категории высокооплачиваемых.
Проверка №6 — Проблемы с сессионными токенами
После успешной авторизации приложение выдает пользователю сессионный токен, который обычно хранится в cookie. Именно он подтверждает, что пользователь уже вошел в систему при выполнении всех последующих запросов.
Если сессионный токен реализован неправильно, вся система аутентификации теряет свою надежность.
Что я проверяю
Случайность токена
Выполняю несколько входов подряд и сравниваю полученные токены. Они должны быть случайными. Если прослеживается закономерность, появляется возможность предсказать следующий токен.
Инвалидация после выхода
После выхода из системы повторно использую старый токен. Если он продолжает работать — это уязвимость. После выхода токен должен быть немедленно аннулирован.
Флаги Secure и HttpOnly
Проверяю параметры cookie через Burp Suite или DevTools браузера.
- Secure — гарантирует передачу cookie только по HTTPS.
- HttpOnly — запрещает JavaScript получать доступ к cookie, снижая риск кражи сессии через XSS.
Отсутствие любого из этих флагов заслуживает внимания при аудите безопасности.
Утечка токенов
Проверяю, не передается ли токен:
- в URL;
- в журналах приложения;
- в теле HTTP-ответов.
Передача токенов через URL особенно опасна, поскольку они сохраняются в истории браузера, логах серверов и могут попасть к третьим лицам.
Почему это важно
Если злоумышленник сможет украсть или предсказать действующий сессионный токен, он получит возможность выполнять действия от имени любого авторизованного пользователя, включая администратора, не зная его пароля.
Мой набор инструментов для тестирования страницы авторизации
При проверке механизма входа я обычно использую следующий набор инструментов:
- Burp Suite Community — перехват, изменение и повторная отправка HTTP-запросов (Repeater, Intruder).
- DevTools браузера — анализ cookie, HTTP-заголовков и ответов сервера.
- ffuf или Hydra — автоматизированное тестирование устойчивости к перебору паролей (только при наличии официального разрешения).
- CyberChef — декодирование и анализ различных токенов и данных.
Однако самый важный инструмент — это системный подход.
Последовательно проходите весь чек-лист и не пропускайте даже самые очевидные проверки. На практике самые простые уязвимости часто остаются незамеченными именно потому, что кажутся слишком банальными.
Важно — тестируйте только те системы, на которые у вас есть разрешение
Все рекомендации, приведенные в этой статье, предназначены исключительно для образовательных целей и проведения санкционированного тестирования безопасности.
Никогда не проверяйте страницы авторизации приложений, владельцы которых не предоставили вам явное разрешение. Несанкционированное тестирование является незаконным независимо от ваших намерений.
Для безопасной практики можно использовать следующие ресурсы:
- TryHackMe — обучающие лаборатории для начинающих специалистов по информационной безопасности.
- PortSwigger Web Security Academy — один из лучших бесплатных ресурсов по тестированию механизмов аутентификации.
- DVWA (Damn Vulnerable Web Application) — уязвимое веб-приложение для локальной практики.
- Hack The Box — платформа для специалистов, желающих повысить уровень практических навыков.
Заключение
Страница входа — это гораздо больше, чем просто форма авторизации. За ней скрываются сразу несколько критически важных компонентов: система аутентификации, управление пользовательскими сессиями, механизм восстановления пароля и потенциальные возможности для сбора информации о пользователях.
Все рассмотренные выше уязвимости регулярно встречаются в реальных Bug Bounty-программах. Их обнаруживают как в небольших проектах, так и в крупных популярных веб-приложениях. И многие из них вполне способны найти даже начинающие специалисты, если знают, на что обращать внимание.
Создайте собственный чек-лист. Используйте его при каждом тестировании. Последовательность и внимание к деталям — одни из главных качеств успешного специалиста по безопасности.
Перевод статьи «Things I Always Check When Testing a Login Page».