На реальном примере:

Уязвимости бизнес-логики:

Уязвимости бизнес-логики требуют ручного вмешательства, поскольку ни один инструмент не может их обнаружить, и они могут варьироваться от приложения к приложению и очень опасны. Мы должны понимать логику приложения, функциональность приложения, реализации и бизнес-требования. Всякий раз, когда мы перехватываем запрос, мы должны манипулировать определенными параметрами в запросе или около того, чтобы проверить уязвимость бизнес-логики.

Типичный пример бизнес-логики:

· Манипуляции с ценой товара в запросе, чтобы мы могли покупать товары за меньшую сумму во время покупок в Интернете.

· Манипуляции с вводом, вводимым пользователем (слишком большое количество или –ve количество), которые не проверяются со стороны сервера.

· Манипуляции в предполагаемом потоке (2FA).

Это уязвимость приложения, возникающая из-за бреши в защите, и у всех разный образ мышления для реализации логики.

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

Бизнес-логика:

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

Пример:

Некоторые приложения не выполняют проверку на стороне сервера, и злоумышленник может манипулировать или обходить проверки на стороне клиента.

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

Как и в случае с продуктом 3, я должен заплатить 13 долларов, если я манипулирую ценой в запросе, он принимается, и я могу легко купить этот продукт по очень низкой цене.

Таким образом, влияние / область уязвимости бизнес-логики очень обширна и зависит от множества факторов. На основе этой уязвимости исследователи безопасности могут заработать приличную сумму.

— — — — — — — — — — — — — — — — — — — — — — — — -

Работа / эксплуатация:

Приложение использует аутентификацию на основе ролей в приложении. Мы должны обойти это, чтобы получить доступ к админке.

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

Согласно приложению, выбранная нами роль устанавливает вашу авторизацию, в ролях нет администратора.

Изначально дерево приложения выглядит так:

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

После обнаружения контента мы видим, что я нашел страницу и каталог с именем «admin».

Теперь я напрямую пытаюсь получить доступ к конечной точке администратора. Я получаю эту ошибку.

Теперь я перехватил запрос на вход, чтобы проверить последовательность входа.

В первом запросе учетные данные перемещались с токеном CSRF.

После пересылки того же запроса

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

Если я перешлю вышеуказанный запрос, он попросит меня выбрать роль.

И как только остановил загрузку запроса (сбросил запрос из отрыжки).

А теперь давайте попробуем посетить конечную точку администратора, поскольку сейчас у нас нет никаких ролей.

Для конечной точки администратора:

Таким образом, просто отбросив запрос, мы получили доступ к учетной записи администратора.

Исправление

· Повторяющееся тестирование кода и соответствие его базе / плану, поэтому становится легко определить надежды на петлю.

· Требуется приложение, которое должно быть проверено экспертами.

· Реализуйте меры безопасности на стороне сервера, чтобы их нельзя было обойти.