Системы аутентификации стали сложнее: к традиционным логину и паролю добавилось активное использование токенов, управление сессиями и интеграция комплексной бизнес-логики.
Но чем сложнее механизм, тем больше шансов допустить ошибку. В реальных пентестах даже крупные компании сталкиваются с критическими уязвимостями в архитектуре и настройке систем аутентификации. Эксперты, разбирают техники пентеста, которые позволяют отработать защиту на практике.
Слабая конфигурация JWT — еще один частый вектор взлома. На практике все еще встречаются маркеры с алгоритмом “none”, предсказуемыми секретными ключами вроде “secret” или “123456”, а также с отсутствием валидации поля “kid”. Распространенный способ атаки — замена RS256 на HS256 с использованием публичного ключа как HMAC-секрета.
Уязвимости проявляются и при несогласованности процессов. Например, сеанс начинается раньше, чем завершается проверка данных, особенно в микросервисной архитектуре. Отдельное внимание требует механизм восстановления доступа: в ряде случаев возможна повторная отправка одного и того же кода, либо отсутствует подтверждение принадлежности почты конкретному пользователю.
Если MFA включен только при входе, работает техника session riding — после захвата сессии злоумышленник может обойти дополнительные факторы защиты. Многоэтапную аутентификацию можно избежать и через техподдержку — MFA иногда отключают после проверки данных для восстановления доступа.
Показательный пример — взлом аккаунта Павла Жовнера, создателя Flipper Zero, в 2025 году. Злоумышленники отправили фишинговое письмо, которое выглядело как официальное уведомление от одной из соцсетей. Домен был похож на адрес настоящего сайта, поэтому сообщение не вызвало подозрений. Хакеры скопировали привычный для Жовнера сценарий: открыть письмо, перейти по ссылке, авторизоваться и подтвердить вход, а также добавили срочность — письмо содержало жалобы на опубликованный контент. В итоге Павел вручную ввел пароль и код MFA, несмотря на предупреждение менеджера паролей.
Типичная ошибка — отсутствие независимой проверки авторизации на уровне каждого элемента. Разработчики часто полагаются на то, что если запрос пришел от другого внутреннего модуля, значит он уже авторизован. Это создает цепочки доверия, которые легко разорвать при компрометации одного из звеньев.
Привилегированный доступ к базе данных представляет отдельный риск. Если приложение подключается к системе с помощью одного универсального пользователя с полными правами, то даже при наличии авторизации на уровне бизнес-логики SQL-инъекция может дать злоумышленнику возможность использования всего содержимого.
Другие уязвимости: кэширование прав с задержкой, при котором привилегии сохраняются даже после смены роли и разница в поведении интерфейса и сервера. Например, фронтенд может ограничивать функции, а бэкенд — нет. Различия между веб- и мобильной версиями могут использоваться для обхода ограничений.
Необычные действия также помогают выявить логические уязвимости. Проверяются ситуации, не предусмотренные обычным пользовательским поведением: отрицательное количество товаров, повторное применение скидки или изменение заказа после оплаты.
К таким нестандартным подходам относятся и тайминговые атаки — они позволяют определить различия в реакции системы. Например, время отклика на валидные и невалидные запросы показывает, какие значения система принимает и как работает проверка на стороне сервера.
Предсказуемые user_id — 1, 2, 3 и так далее — открывают путь к IDOR-атакам. Особенно это критично в REST API, где структура “/api/user/{id}” позволяет перебором получить чужие профили. Подобный риск существует и при использовании timestamp-идентификаторов.
Иногда токены генерируются по упрощенному алгоритму, например, MD5 зависит от user_id и текущего времени (timestamp). Такой подход облегчает создание валидного ключа без обращения к серверу. Особо чувствительны в этом плане старые самописные фреймворки.
Только ручное тестирование помогает обнаружить сложные цепочки атак, состоящие не из одной уязвимости, а из их комбинации. Например, связка IDOR, утечки данных и захваченной сессии может привести к полной компрометации системы. Автоматические инструменты не улавливают такие взаимосвязи — они проверяют каждый элемент изолированно.
Кроме того, автоматические инструменты не учитывают и человеческий фактор — поведение пользователя, ошибки конфигурации и утечку доступа через разработчиков.
Но чем сложнее механизм, тем больше шансов допустить ошибку. В реальных пентестах даже крупные компании сталкиваются с критическими уязвимостями в архитектуре и настройке систем аутентификации. Эксперты, разбирают техники пентеста, которые позволяют отработать защиту на практике.
Рабочие техники обхода
Один из самых устойчивых и эффективных методов обхода, который используют злоумышленники — атака на сессии. Предсказуемые идентификаторы и отсутствие XSS-защиты упрощают перехват или подделку токенов аутентификации. Особенно уязвимы WebSocket-соединения, где данные часто передаются без шифрования и валидации, что позволяет получить несанкционированный доступ к аккаунтам.Слабая конфигурация JWT — еще один частый вектор взлома. На практике все еще встречаются маркеры с алгоритмом “none”, предсказуемыми секретными ключами вроде “secret” или “123456”, а также с отсутствием валидации поля “kid”. Распространенный способ атаки — замена RS256 на HS256 с использованием публичного ключа как HMAC-секрета.
Уязвимости проявляются и при несогласованности процессов. Например, сеанс начинается раньше, чем завершается проверка данных, особенно в микросервисной архитектуре. Отдельное внимание требует механизм восстановления доступа: в ряде случаев возможна повторная отправка одного и того же кода, либо отсутствует подтверждение принадлежности почты конкретному пользователю.
Ошибки в реализации MFA
Многофакторная аутентификация снижает риски несанкционированного входа, но не исключает их полностью. На практике встречаются типовые ошибки, например, небезопасное хранение резервных кодов, а иногда используются предсказуемые шаблоны, которые значительно упрощают подбор.Если MFA включен только при входе, работает техника session riding — после захвата сессии злоумышленник может обойти дополнительные факторы защиты. Многоэтапную аутентификацию можно избежать и через техподдержку — MFA иногда отключают после проверки данных для восстановления доступа.
Показательный пример — взлом аккаунта Павла Жовнера, создателя Flipper Zero, в 2025 году. Злоумышленники отправили фишинговое письмо, которое выглядело как официальное уведомление от одной из соцсетей. Домен был похож на адрес настоящего сайта, поэтому сообщение не вызвало подозрений. Хакеры скопировали привычный для Жовнера сценарий: открыть письмо, перейти по ссылке, авторизоваться и подтвердить вход, а также добавили срочность — письмо содержало жалобы на опубликованный контент. В итоге Павел вручную ввел пароль и код MFA, несмотря на предупреждение менеджера паролей.
Уязвимости в архитектуре
К архитектурным уязвимостям относят ошибки во взаимодействии между компонентами и уровнями системы. Их трудно устранить точечно: даже если закрыть один из недочетов, инфраструктура в целом остается подверженной атаке, что особенно характерно для микросервисной архитектуры.Типичная ошибка — отсутствие независимой проверки авторизации на уровне каждого элемента. Разработчики часто полагаются на то, что если запрос пришел от другого внутреннего модуля, значит он уже авторизован. Это создает цепочки доверия, которые легко разорвать при компрометации одного из звеньев.
Привилегированный доступ к базе данных представляет отдельный риск. Если приложение подключается к системе с помощью одного универсального пользователя с полными правами, то даже при наличии авторизации на уровне бизнес-логики SQL-инъекция может дать злоумышленнику возможность использования всего содержимого.
Другие уязвимости: кэширование прав с задержкой, при котором привилегии сохраняются даже после смены роли и разница в поведении интерфейса и сервера. Например, фронтенд может ограничивать функции, а бэкенд — нет. Различия между веб- и мобильной версиями могут использоваться для обхода ограничений.
Поиск нестандартных векторов
Пентестеры анализируют бизнес-логику и ищут нетипичные способы обхода защиты. Один из приемов — поиск забытых или скрытых API-эндпоинтов, особенно в легаси-системах и микросервисах. Такие точки могут остаться доступными без авторизации: они не отображаются в UI, а для обнаружения используют парсинг JavaScript, автоматические сканеры и ручной анализ.Необычные действия также помогают выявить логические уязвимости. Проверяются ситуации, не предусмотренные обычным пользовательским поведением: отрицательное количество товаров, повторное применение скидки или изменение заказа после оплаты.
К таким нестандартным подходам относятся и тайминговые атаки — они позволяют определить различия в реакции системы. Например, время отклика на валидные и невалидные запросы показывает, какие значения система принимает и как работает проверка на стороне сервера.
Токены, cookie и ID как точка входа
Анализ авторизационных токенов помогает раскрыть много информации. В JWT полезно декодировать payload и выявлять дополнительные claims, такие, как “is_admin”, “debug, “dev”. Изменение одного поля может привести к эскалации прав при слабой валидации.Предсказуемые user_id — 1, 2, 3 и так далее — открывают путь к IDOR-атакам. Особенно это критично в REST API, где структура “/api/user/{id}” позволяет перебором получить чужие профили. Подобный риск существует и при использовании timestamp-идентификаторов.
Иногда токены генерируются по упрощенному алгоритму, например, MD5 зависит от user_id и текущего времени (timestamp). Такой подход облегчает создание валидного ключа без обращения к серверу. Особо чувствительны в этом плане старые самописные фреймворки.
Ошибки в реализации OAuth и SSO
Неправильная реализация OAuth и SSO часто становится причиной обхода аутентификации. Типичные ошибки: недостаточная проверка redirect URI, отсутствие проверки параметра “state”, необходимого для защиты от CSRF, и возможность изменения scope без валидации. Утечка ключей через referrer-заголовки, слабая реализация PKCE в мобильных приложениях и использование устаревшего implicit flow создают дополнительные уязвимости. Еще одна частая проблема –– неполный logout в приложениях, использующих одного провайдера SSO, из-за чего доступ сохраняется даже после выхода из системы.Ошибки DevOps и CI/CD
Автоматизация деплоя и ускоренные процессы разработки часто приводят к критическим уязвимостям. Основные ошибки:- дефолтные пароли в контейнерах;
- secrets в переменных окружения, видимых другими процессами или логами;
- ошибки в настройке reverse proxy, позволяющие обходить этап входа в систему;
- debug-эндпоинты в production (Spring Boot Actuator и пр.);
- некорректные CORS-политики, допускающие междоменный доступ;
- запуск контейнеров в режиме “--privileged”;
- утечка секретов в CI/CD логах;
- хардкод секретов в IaC-решениях (Terraform, Ansible и т.п.).
Почему автоматического сканирования недостаточно
Автоматические сканеры выявляют лишь стандартные уязвимости и не учитывают сложные сценарии, связанные с логикой приложения и поведением пользователей.Только ручное тестирование помогает обнаружить сложные цепочки атак, состоящие не из одной уязвимости, а из их комбинации. Например, связка IDOR, утечки данных и захваченной сессии может привести к полной компрометации системы. Автоматические инструменты не улавливают такие взаимосвязи — они проверяют каждый элемент изолированно.
Кроме того, автоматические инструменты не учитывают и человеческий фактор — поведение пользователя, ошибки конфигурации и утечку доступа через разработчиков.
