Приветствую, коллеги!
В новой статье рассмотрим 4 простых кейса с площадки PortSwigger, посвященных уязвимости бизнес-логики приложений. Мы затронем уязвимость в оплате онлайн магазина и аутентификации приложения.
Приступим к разбору!
Немного теории
Уязвимость бизнес-логики — это тип уязвимости, при котором система работает «как задумано» с технической точки зрения, но сама логика процесса позволяет злоумышленнику получить выгоду или нарушить правила.
Суть в том, что система доверяет определённому сценарию поведения пользователя: например, что он пройдет шаги в нужном порядке, не будет повторять действия или менять параметры запросов. Если эти ожидания не контролируются на сервере, пользователь может обойти ограничения и получить результат, который по логике должен быть недоступен. При этом никакого «взлома» в привычном смысле может не происходить — всё выглядит как обычные запросы к системе.
Такие уязвимости часто связаны с отсутствием проверки состояния, неправильной обработкой последовательности действий или излишним доверием к данным с клиента. Из-за этого можно, например, получить доступ к желаемому функционалу раньше времени, использовать преимущества несколько раз или выполнить действие без необходимых условий.
Главная проблема в том, что это не технический дефект, а логическая ошибка в проектировании. Поэтому такие уязвимости сложно находить автоматически — их обычно выявляют через анализ поведения системы и понимание того, как она должна работать на уровне бизнес-процессов.
Чрезмерное доверие к средствам контроля на стороне клиента
В онлайн магазине при входе у нас есть небольшая сумма, с которой тут особо не разгуляться.
Ваша основная цель для решения таска - купить куртку на первой странице магазина. Для этого добавим её в корзину и посмотрим на запросы:
Найдём наш POST-запрос в истории. Там же обнаруживаем параметр price с ценой товара 133700 тумбриков (это цена с копейками). Это явно дороговато. Также в запросе фигурирует кол-во товаров при покупке (quantity) и ID товара.
Попробуем поторговаться с сайтом и изменим значение цены на 1 тумбрик. Предположим, что сервер не перепроверяет запросы, а слепо верит им без перепроверок.
После чего видим, что цена на товар теперь немного меньше изначальной:
Т.к. у нас изначально было только 100$, то сбив цену, за 0.03$ мы урвали 3 товара по такой выгодной акции.
Уязвимость в логике высокого уровня
В следующем задании нам необходимо купить тот же товар (куртку), но при помощи одной ошибки в логике приложения можем сбить цену.
Принцип следующий: при исследовании запросов обнаруживаем, что кол-во товара может быть изменена на отрицательную. За счёт такого трюка мы можем сбить цену дорогому товару и сделать его доступнее для нас. Общая сумма товара пересчитается из-за отрицательного значения цены второго товара и мы снова прикупим шмотку.
Так и поступаем!
Как видите, товар теперь стоит чуть более 8 тумбриков. Это нам по карману.
Непоследовательные меры безопасности
Теперь затронем ошибку бизнес-логики в аутентификации. Для входа в /admin необходимо быть зареганным как сотрудник компании с доменом @dontwannacry.com. Остальные домены не принадлежат сотрудникам данной компании и следовательно не имеют прав администратора на сайте.
Попробуем зарегать обычного пользователя и укажем почтовый адрес, выданный в лабе, для получения письма с подтверждением учётки.
На почте attacker будет лежать письмо с подтверждением:
Т.к. наш домен exploit-....net, то и прав продвинутого пользователя тоже отсутствуют. Но, важно то, что у нас теперь есть учётка. И тут кроется как раз и та самая ошибка в логике.
На сайте есть возможность поменять почтовый ящик, однако подтверждать его уже не требуется. Мы же это сделали ранее с другой почтой... Это и породило уязвимость в логике.
Изменив наш домен на корпоративный, получаем права админа и завершаем таск, удалив бедного carlos.
Неправильное применение бизнес-правил
Теперь рассмотрим ошибку логики в применении бонусных кодов на скидку. Изначально нам дают кода для получения скидки в 5 тумбриков. Этого нам опыт же недостаточно для покупки очередной куртки.
Ниже данной формы можно получить новый промокод, введя почтовый адрес, который никак не проверяется.
Новый промо появится в сплывающем окне:
И вот в чём тут ошибка в логике: приложение запоминает последний использованный промокод, а не использованный в системе в целом. То есть, воспользовавшись новым промокодом - теперь он является последним используемым. Значит теперь можно попробовать использовать первый промокод и получить ещё одну скидку.
Таким образом, по цепочке, чередуя промокоды, получаем значительную скидку и обзаводимся новой курткой.
Если завтра у себя на районе увидите новый ларёк с одинаковыми куртками в продаже, то это я.
Выводы
Бизнес-логика довольно сложная уязвимость в её обнаружении. Для этого нужно подробно понимать как протекают процессы в приложении, что и даёт возможность пробовать модифицировать его, чтобы добиться иного результата.
Это были простые и довольно понятные кейсы для знакомства с данной уязвимостью. Далее разберём задания сложнее.
Спасибо за внимание! Не забывайте оценивать моё творчество лайком. Всех благ!