Взлом — это не только дамп базы, компрометация учёток, SQLi, XSS или что-то с максимально кинематографичным названием.

Иногда взлом выглядит намного прозаичнее. ➢ Без масок, без красных экранов, без «я получил root».

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

И вот как раз с этого я и хочу начать. Потому что сегодня речь не про критическую уязвимость, не про утечку, не про захват аккаунтов и не про инъекции.

Сегодня речь про куда более бытовую, но очень показательную вещь про уязвимость бизнес-процесса

━━━━━━━━━━ Что такое уязвимость бизнес-процесса ━━━━━━━━━━

Уязвимость бизнес-процесса, или business logic vulnerability, — это ошибка в логике работы приложения, из-за которой пользователь может вызвать непредусмотренное поведение, используя при этом вполне легитимную функциональность системы. ➢ PortSwigger определяет её как flaw в дизайне или реализации приложения, который позволяет атакующему добиться нежелательного результата через обычные механики продукта. Иначе говоря, проблема не обязательно в «опасном payload», а в том, что сама система неправильно описала или слабо защитила свои правила.

Как это выглядит на практике: • лимит на действие заявлен, но его можно обойти • шаги процесса должны идти последовательно, но их можно менять местами; • значение должно быть только положительным, но система принимает null или -1 • клиент показывает «нельзя», а сервер по факту это «можно» принимает; • одноразовое действие можно повторить несколько раз

Типовые примеры:

• Доступ в привилегированную зону через рассинхрон обработки e-mail Продукт говорит: доступ в админку или внутренние функции есть только у сотрудников с корпоративной почтой. Но одна часть системы проверяет адрес как строку, а другая парсит его по своим правилам. В итоге можно подобрать нестандартный формат адреса так, чтобы проверка сочла тебя «сотрудником», хотя ящик на самом деле контролируешь ты. Это уже не баг поля ввода, а ошибка в самой логике принятия решения.

• Обход ограничения, которое держится только на стороне клиента Интерфейс не даёт поменять цену, количество, длину текста или другой важный параметр, но сам параметр всё равно уходит в запросе. Дальше логика простая: перехватываешь HTTP-запрос, вручную меняешь значение и смотришь, перепроверяет ли это сервер. Если не перепроверяет — ограничение было только в UI, а не в системе. Это классический кейс excessive trust in client-side controls.

• Обход процесса входа из-за неправильной последовательности шагов Например, после логина система должна провести тебя через дополнительный этап выбора роли или подтверждения. Но если один промежуточный шаг можно выбросить или обойти, приложение может выдать более привилегированное состояние, чем должно. То есть взлом тут не в подборе пароля, а в том, что backend слишком верит ожидаемой цепочке действий.

Интерфейс может подсвечивать, подсказывать и ограничивать для удобства, но не должен быть последней линией обороны. Всё, что UI «не давал внести», часто всё равно можно отправить вручную: достаточно перехватить запрос, изменить параметр и передать на сервер то значение, которое визуально было запрещено.

━━━━━━━━━━ Что такое валидация на стороне клиента ━━━━━━━━━━

Валидация на стороне клиента — это проверка данных до отправки запроса на сервер, прямо в браузере пользователя. ➢ Её задача обычно простая: быстро подсветить ошибку, не дать ввести совсем некорректное значение и сделать форму удобнее. То есть это в первую очередь про UX и предварительный контроль, а не про реальную границу безопасности.

Как это обычно реализуют: • через HTML-ограничения вроде maxlength, required, type="email", min, max, pattern; • через JavaScript-проверки на input, change, submit; • через маски ввода, запрет определённых символов, блокировку кнопки отправки, выпадающие списки с «разрешёнными» значениями; • через визуальные сообщения в духе «слишком длинный текст», «неверный формат почты», «значение вне диапазона». Всё это удобно для пользователя, но живёт в его же браузере и потому не может считаться надёжной защитой само по себе.

Пара простых примеров: • форма не даёт ввести больше n объектов в корзину; • корзина не позволяет указать количество меньше 1; • интерфейс запрещает менять цену товара; • форма регистрации принимает только «правильный» формат e-mail; • кнопка отправки остаётся неактивной, пока пароль не соответствует правилам. На уровне интерфейса всё выглядит строго, но это строгость ровно до того момента, пока пользователь не решит проверить, что реально принимает backend.

Чем это опасно: • браузер находится под контролем пользователя; • клиентский код можно изучить, отключить или обойти; • запрос можно перехватить прокси, изменить параметр вручную и отправить на сервер уже не то значение, которое позволял UI;

━━━━━━━━━━ Обход процесса входа из-за неправильной последовательности шагов ━━━━━━━━━━

Суть проблемы — приложение считает, что вход в систему всегда будет идти по строго ожидаемому сценарию: сначала логин, потом промежуточный шаг, потом выбор роли, подтверждение или редирект на нужную страницу ➢ Но если backend жёстко не контролирует этот порядок, то часть шагов можно пропустить, оборвать или вызвать вне контекста, и система всё равно переведёт пользователя в более привилегированное состояние. Именно такой кейс PortSwigger показывает в лабе про authentication bypass via flawed state machine: ошибка не в пароле, а в том, что сама последовательность входа оказалась ненадёжной.

Как это обычно выглядит ➊ пользователь проходит первый шаг логина; ➋ приложение создаёт промежуточное состояние сессии; ➌ дальше должен быть ещё один обязательный шаг: выбор роли, 2FA, подтверждение, принятие контекста; ➥ но если этот шаг можно не завершать, прервать или обойти, система иногда назначает состояние по умолчанию или просто считает процесс завершённым.

━━━━━━━━━━ Подводим итоги ━━━━━━━━━━

Почему мне нравится эта тема? ➢ Потому что она отлично напоминает простую вещь: безопасность — это не только поиск страшных технических багов.

Безопасность — это ещё и проверка того, насколько система в принципе умеет быть честной со своими же правилами. Иногда самый полезный вопрос к продукту звучит не как «есть ли тут RCE?» а как ➢ «а ты точно реально запрещаешь то, что заявляешь как запрещённое?»

Если свести всё к одной мысли, то она будет очень простой: уязвимости бизнес-процессов опасны не только последствиями, но и тем, что показывают слабые места в логике доверия системы.

#AppSec #Security #BugBounty #Frontend #Backend #IT #БизнесЛогика #Валидация #Сетка