Auth Attacks — часть 3: другие механизмы аутентификации

🔷Тип: Web, Server-Side

➡️ Session management

• 🦴 Session Fixation - возможность заполучить валидную сессию или заставить пользователя выполнить логин под специально созданной с возможностью ее переиспользования в дальнейшем.
• 🦴 Impoper Invalidation - некорректные механизмы инвалидации сессий/токенов, которые приводят к возможности переиспользования в случаях, когда истекло время или пользователь вышел из аккаунта. Встречается чуть ли не в каждом втором приложении, но использовать это в реальных условиях очень сложно.

➡️ Custom auth cookie

• 🦴 Cookie guessing - если понять принцип формирования кастомной куки, можно подменить/подобрать значение и получить ATO (Account Takeover).
• 🦴 Insecure deserialization - если для кастомной куки используется сериализация, бывает возможным проведение атак небезопасной десериализации, что при успехе может приводить к RCE

➡️ Password Reset

• 🦴 Token Guessing - токены со слабой энтропией или логическими ошибками можно легко подобрать
• 🦴 SQL injection Ultimate power - если приложение имеет где-то SQL-инъекцию и функционал восстановления паролей - это легчайший путь к ATO, потому что обычно эти токены хранятся в базе данных и почти никогда не шифруются (в отличие от паролей)
• 🦴 Broken Access Control - есть много способов провернуть (включая логические баги, например различная интерпретация поля email по RFC), но суть вектора - смена паролей других пользователей
• 🦴 Host Header Attack - подмена заголовка Host (или аналогичных) при отправке запроса на восстановление пароля, что может привести к отправке жертве поддельной ссылки, при переходе по которой токен восстановления улетает к атакующему. Очень красивая атака, даже в боевом приложении один раз видел.
• 🦴 Exotic Exploits - использования необычных техник эксплуатации, которые могут результровать в угоне аккаунта. Как пример - Dangling Markup-инъекция в отправляемое сообщение
• 🦴 Flood/User Enumeration

➡️ Password Change

• 🦴 Broken Access Control - также много способов, суть та же самая: смена пароля другому пользователюю
• 🦴 Logic Flaws - логические проблемы, которые позволяют в той или иной степени облегчить сценарий эксплуатации атак на аутентификацию. В некоторых случаях позволяет перебирать пароли пользователей без негативных эффектов для самой учетной записи (не вызывая ее блокировку)
• 🦴 Prototype Pollution (Server-Side) - подробнее будет описано далее в этом посте

➡️ Custom CAPTCHA

Как и любое кастомное решение - красная тряпка для любого исследователя безопасности. Проблем тут может быть очень много, среди наиболее популярных:

• 🦴 CAPTHCA Guessing - возможность угадать/получить от приложения ответ на капчу
• 🦴 CAPTHCA Modify - возможность заменить значение CAPTCHA на подконтрольное/необходимое
• 🦴 CAPTHCA DoS - наверное, самая частая проблема в кастомных капчах - возможность испортить капчу/несколько капч по идентификатору, деля невозможным ввести верный ответ, а следовательно и войти в аккаунт

➡️ Registration

• 🦴 Mass Assignment - возможность внедрения валидных атрибутов в форму регистрации, что может привести к получению дополнительных привилегий в приложении
• 🦴 Prototype Pollution (Server-Side) - экзотика, но если бекенд приложения работает на JavaScript, потенциально можно переписать прототип объектов и либо получить тот же эффект, что и от Mass Assignment, либо получить RCE, либо вызвать DoS всего приложения (обычно, самый вероятный исход). Позже сделаю качественный пост на эту тему.
• 🦴 Flood/User Enumeration

➡️ JWT, OAUTH

Имеют свои собственные пути эксплуатации, и это снова тема будущих постов) Упомянуто в здесь, потому что наличие данных механизмов всегда должно инициировать дополнительные проверки типовых уязвимостей подобных систем.

#edu #vuln #web #auth
Hunt Or Be Hunted