Инструментарий санкционированного пентеста платёжных шлюзов (для white‑hat)

[Good Carder]

Введение: почему платежные API — особая цель​

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

В этой статье мы разбираем методологию тестирования платежных шлюзов Stripe и Adyen через призму OWASP API Security Top 10, поиск race condition, подделку вебхуков, перехват OAuth-токенов и инструменты, которые делают эту работу возможной. Всё изложенное относится исключительно к санкционированному пентесту с письменного разрешения владельца системы.

Часть 1. OWASP API Security Top 10 применительно к Stripe и Adyen​

OWASP API Security Top 10 2023 — это актуальный стандарт, определяющий критические риски API, включая некорректное управление объектами и функциями, недостатки аутентификации и неограниченное потребление ресурсов.

1.1. API1:2023 – Broken Object Level Authorization (BOLA)​

Это самая распространенная и критическая уязвимость платежных API. Хакер, меняя идентификатор объекта в запросе (например, payment_intent_id или customer_id), может получить доступ к чужим данным, не принадлежащим его сессии.

Что тестировать в Stripe и Adyen:

• Возможность подменить payment_method_id или customer_id в запросе на создание платежа.
• Доступ к вебхукам других мерчантов через изменение идентификатора в запросе.
• Возможность просмотра чужих чарджбэков или отчетов о выплатах.

Инструментарий: Burp Suite Intruder для подстановки ID в параметры запросов, автоматизированный перебор с помощью пользовательских словарей. При тестировании BOLA важно не только проверить прямые ID, но и объекты, доступные через вложенные структуры (например, payment_intent.charges.data[].customer).

1.2. API2:2023 – Broken Authentication​

Тестируем весь цикл аутентификации: от получения client_secret до обновления токенов и выхода из системы.

Ключевые точки в Stripe:

• client_secret используется в клиентской части (stripe.confirmCardPayment). Проверьте, можно ли подменить client_secret в консоли браузера, чтобы подтвердить чужой платёж.
• Refresh token race condition. Stripe поддерживает ротацию refresh token при каждом обновлении. В многопроцессной среде без блокировки возможна ситуация, когда разные процессы одновременно обновляют токен, что приводит к сбою с ошибкой invalid_grant, так как один процесс использует уже недействительный refresh token.

При тестировании аутентификации важно проверить, как система обрабатывает параллельные запросы на обновление токенов, и не возвращается ли старый refresh token как валидный после ротации.

OAuth 2.0 в платежных системах: Stripe использует OAuth для подключения платформ; Adyen — для безопасной доставки вебхуков. Тестируйте:

• Возможность перехвата и повторного использования кода авторизации.
• Наличие защиты от CSRF в конечных точках OAuth.
• Корректность проверки редиректов (открытые редиректы в callback URI).

1.3. API3:2023 – Broken Object Property Level Authorization (BOPLA)​

Хакер получает доступ к объекту (например, к своему платёжному интенту), но может манипулировать свойствами, которые ему не разрешено изменять.

Что тестировать:

• Возможность подменить statement_descriptor и receipt_email в PaymentIntent.
• Изменение description или metadata в чужом объекте.
• Доступ к полям card_present или payment_method_details, которые обычно раскрывают чувствительную информацию, но могут быть доступны через недокументированные эндпоинты. В Adyen API проверять параметр additionalData — при определенных условиях он может изменить ход обработки платежа (например, применив неправомерный штраф).

1.4. API5:2023 – Broken Function Level Authorization​

Что тестировать:

• Использование административных функций (например, v1/accounts/{id}/reject в Stripe Connect) из обычного аккаунта.
• Доступ к эндпоинтам отмены/возврата через подстановку ID чужой транзакции.
• Вызов функций, предназначенных только для внутреннего использования (например, v1/radar), извне.

1.5. API8:2023 – Security Misconfiguration​

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

Что проверять:

• Открыт ли доступ к эндпоинтам /v1/setup_intents или /v1/payment_methods без проверки прав в Stripe?
• Активированы ли неиспользуемые методы платежей (например, неотключенные тестовые шлюзы) в Adyen?
• Присутствует ли подробная информация об ошибках в ответах API (stack trace и внутренние пути) — признак конфигурации отладки, не предназначенной для продакшена.
• Работает ли проверка подписи вебхуков с пустым секретом в Stripe (CVE-2026-41432)?

1.6. PSD2 и Open Banking Compliance​

Для пентеста платежных систем в Европе критически важно тестирование на соответствие PSD2. Основные требования:

• Strong Customer Authentication (SCA) проверяется на всех типах транзакций и требует как минимум двух независимых факторов аутентификации.
• Динамическая привязка (Dynamic Linking) гарантирует, что одноразовый код привязан к конкретной сумме транзакции и получателю платежа. Тестируйте возможность подменить сумму после прохождения SCA.
• OAuth 2.0 и mTLS для Open Banking. Тестируйте валидацию сертификатов (проверьте, принимает ли API самоподписанный сертификат с истекшим сроком действия), невозможность эскалации привилегий (read‑only токен не должен инициировать платежи) и защиту от перехвата кода авторизации.

1.7. Уязвимости имплементации Adyen​

При тестировании Adyen важны:

• HMAC-подпись вебхуков на основе SHA256 (обязательная проверка).
• Конечные точки OAuth 2.0 для безопасной доставки нотификаций — проверяйте, можно ли подменить заголовок авторизации и получить доступ к чужим событиям.

Часть 2. Поиск race condition в обработке транзакций​

Race condition — одна из самых опасных уязвимостей платежных систем. Она возникает, когда два параллельных процесса одновременно обращаются к общему ресурсу, и результат зависит от того, какой процесс завершится первым. В контексте платежей race condition может привести к двойному зачислению средств, повторному списанию с карты или предоставлению товара/услуги без реальной оплаты.

2.1. Race condition при одновременном подтверждении платежа​

Стандартный сценарий: веб-приложение создает PaymentIntent в Stripe и передает client_secret клиенту. Клиент вызывает stripe.confirmCardPayment, и Stripe подтверждает платеж. Получив вебхук payment_intent.succeeded, сервер зачисляет средства пользователю. Проблема возникает, когда один и тот же client_secret используется в двух параллельных запросах к Stripe. Один запрос может списать средства, а второй — завершиться ошибкой, но оба могут быть интерпретированы сервером как успешные, если код вебхука не обрабатывает статус должным образом.

Техника тестирования:

1. Перехватите запрос подтверждения платежа в Burp Suite (Repeater).
2. Отправьте два идентичных запроса максимально быстро (задержка между запросами не должна превышать 5-10 мс). Для автоматизации можно написать скрипт на Python с использованием потоков.
3. Наблюдайте, создаются ли две успешные транзакции (два успешных payment_intent с разными id).
4. Если создаются, проверьте, может ли хакер использовать это для получения товара или услуги без оплаты в пределах одной легитимной транзакции.

Stripe в целом хорошо защищен от race condition благодаря идемпотентности, но уязвимости возможны в пользовательском коде обработки вебхуков, особенно если обработчик не является идемпотентным.

Реальный пример: В одном из проектов код обработки Stripe вебхуков выполнял синхронную запись в базу данных внутри обработчика. При высокой нагрузке (ожидании более 30 секунд) Stripe повторно отправлял вебхук, который не получил ответа 200 OK вовремя. В результате одна и та же транзакция обрабатывалась дважды, создавая двойное зачисление средств. Проблема была исправлена переходом на асинхронную очередь: вебхук только сохраняет событие, а отдельный воркер обрабатывает его позже.

2.2. Race condition при обработке idempotency keys​

Идемпотентность — когда повторная отправка одного и того же запроса с одинаковым Idempotency-Key не приводит к повторному списанию. Stripe гарантирует, что первый запрос с данным ключом будет обработан, а последующие с тем же ключом вернут тот же результат без повторного списания.

Что тестировать: отправьте два идентичных запроса на создание платежа с одинаковым Idempotency-Key одновременно. Проверьте, создадутся ли два платных PaymentIntent. Если да — race condition в реализации идемпотентности. В Stripe для предотвращения таких сценариев используется механизм блокировок, но на уровне интеграции могут возникать проблемы, когда два сервера создают одинаковые ключи.

2.3. Race condition при балансировке остатка​

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

Как тестировать: создайте аккаунт с минимальным балансом (например, 10). Одновременно отправьте два запроса на списание 7 (это возможно только при использовании разных Idempotency-Key). Если оба списания успешны — баланс стал отрицательным (10—7—7=−4), но платформа может разрешить транзакцию, что приводит к неограниченному выводу средств.

Часть 3. Подделка webhook-событий и аутентификация​

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

3.1. Атаки на подпись вебхуков Stripe​

Stripe подписывает каждый вебхук с помощью секретного ключа (whsec_*), который должен храниться на сервере продавца. По умолчанию Stripe требует, чтобы в коде было установлено значение StripeWebhookSecret, которое не должно быть пустым.

Критическая уязвимость 2026 года (CVE-2026-41432): Если StripeWebhookSecret остается пустым (значение по умолчанию), HMAC-подпись вычисляется с пустым ключом. Любой хакер может подделать вебхук с правильной подписью, сгенерированной тем же алгоритмом с пустым ключом. В сочетании с отсутствием проверки payment_status == "paid" хакер может подделать успешное событие checkout.session.completed, чтобы пополнить свой внутренний счет без реальной оплаты. Уязвимость была исправлена в версии 0.12.10.

Как тестировать в рамках санкционированного пентеста:

1. Проверьте, настроен ли в среде Stripe секрет вебхука (он не должен быть пустым).
2. Проверьте, есть ли в коде обработчика проверка подписи с использованием библиотеки Stripe::Webhook.construct_event.
3. Проверьте, выполняется ли проверка event.type == "checkout.session.completed" И event.data.object.payment_status == "paid" до зачисления средств.
4. С помощью stripe listen --forward-to localhost:3000/webhooks перехватите легитимный вебхук и попробуйте изменить его параметры (сумму, статус). Сервер должен отклонить поддельный вебхук из-за недействительной подписи.

Важно также проверить, как обрабатываются checkout.session.async_payment_succeeded и checkout.session.async_payment_failed для платежей с задержкой (например, банковский перевод). Если они не обрабатываются, средства могут быть зачислены, а затем отозваны.

3.2. Атаки на вебхуки Adyen​

Adyen поддерживает HMAC-подпись SHA256 и OAuth 2.0 для аутентификации вебхуков. Для Standard Webhooks рекомендуется использовать OAuth 2.0, при этом подпись HMAC должна проверяться независимо от метода аутентификации. Важно проверить, что вебхуки действительно аутентифицируются либо по HMAC, либо по OAuth, и система не принимает запросы без валидной авторизации.

Что тестировать:

• Использует ли конечная точка правильную проверку HMAC (включая проверку домена и IP).
• Корректно ли обрабатываются таймауты (10 секунд) — не приводит ли долгий ответ к повторной отправке и дублированию событий.
• Настроена ли повторная отправка для уведомлений, оставшихся в очереди более чем на 30 дней.
• Работает ли функция фильтрации событий, чтобы хакер не мог получать нежелательные нотификации.

3.3. Кросс-гейтвейная эксплуатация (Adyen и Stripe)​

В CVE-2024-41432 отсутствовала проверка поля PaymentMethod. Заказ, созданный через Epay (или другой неподдерживаемый шлюз), может быть выполнен с помощью поддельного вебхука Stripe.

Как тестировать в рамках санкционированного пентеста:

• Создайте заказ через платежный метод Epay или Cash.
• Отправьте поддельный вебхук checkout.session.completed на конечную точку Stripe вашего приложения.
• Если заказ выполняется и зачисляются средства, приложение уязвимо для кросс-гейтвейной эксплуатации.

Часть 4. Перехват OAuth-токенов и аутентификация платежей​

OAuth 2.0 широко используется платежными системами для авторизации сторонних приложений, доступа к API и безопасной доставки вебхуков. Утечка токена аутентификации может привести к полному захвату аккаунта продавца.

4.1. Основные векторы атак на OAuth​

Перехват кода авторизации (authorization code interception) происходит, когда хакер перехватывает код авторизации при передаче от провайдера (Stripe, Adyen) к приложению. Техники защиты включают:

• Использование PKCE (Proof Key for Code Exchange).
• Хранение code_challenge и code_verifier в сессии с защитой от CSRF.
• Привязка callback-URI к валидному домену (open redirect). Stripe и Adyen требуют точного совпадения — это важная проверка.

CSRF в конечных точках OAuth возникает, когда хакер создает поддельный запрос авторизации от имени жертвы. Защита обеспечивается параметром state (уникальная строка, связанная с сессией). При тестировании проверяйте, не отсутствует ли проверка state в конечной точке обратного вызова.

Утечка токенов из логов и сниффинг — еще один распространенный сценарий. Все запросы, содержащие токены, должны проходить только по TLS 1.2+ и не должны логироваться в открытом виде.

4.2. Перехват токенов в Stripe и Adyen​

Stripe OAuth:

• Токены (access_token и refresh_token) используются для доступа к Stripe API от имени подключенного аккаунта.
• Refresh token действителен в течение года, но при обновлении Stripe выполняет ротацию токенов: оба токена заменяются на новую пару, а старый refresh token становится недействительным.

Race condition при обновлении токенов: если два сервера одновременно пытаются обновить токен, возможна ошибка invalid_grant, так как один процесс использует уже недействительный refresh token. Это не уязвимость Stripe, а ошибка интеграции, приводящая к сбоям.

Adyen OAuth 2.0: Adyen использует OAuth-токены для безопасной отправки вебхуков. Токен отправляется в заголовке Authorization каждого вебхука. Проверьте, что ваш вебхук-эндоинт проверяет валидность заголовка Authorization и не принимает поддельные запросы без него.

Что тестировать в рамках санкционированного пентеста:

• Утечку токенов в клиентском коде (файлы .js).
• Хранение refresh token в логах.
• Передачу токенов через открытые каналы.
• Корректность ревокации токенов при смене пароля или отзыве доступа.

Часть 5. Инструментарий тестирования: от Burp Suite до кастомных фуззеров​

5.1. Burp Suite Pro — основа пентеста​

Burp Suite Pro перехватывает, анализирует и модифицирует HTTP/HTTPS/HTTP2-запросы, включая API-вызовы Stripe и Adyen. Все запросы легко модифицировать в прокси. Основные функции:
Repeater — ручное изменение и повторная отправка запросов. Используется для проверки BOLA и race condition с задержкой между запросами.
Intruder — автоматизация атак на основе подстановок. Для тестирования BOLA Intruder подставляет различные payment_intent_id и анализирует ответы.
Scanner (Pro) — автоматическое сканирование API-эндпоинтов, включая проверку SQL-инъекций, XSS и утечек конфиденциальных данных.
Extensions — расширения, такие как API Sniffer, автоматически находят API-ключи в проксированном трафике и добавляют их в Issues.

С 2021 года в Burp Suite Professional и Enterprise Edition доступна функция «API‑only scan», позволяющая загружать спецификации API (OpenAPI, SOAP WSDL) для автоматического сканирования.

5.2. Postman для функционального тестирования​

Postman — мощный инструмент для ручного и автоматизированного тестирования API:

• Импортируйте официальные коллекции API Stripe и Adyen.
• Используйте переменные коллекции (например, {{stripe_secret_key}}) для хранения ключей.
• Пишите тесты на JavaScript для проверки статусов ответов и схем данных.
• Используйте Pre‑request Scripts для динамического создания неидентичных запросов (например, разных Idempotency-Key для каждого запроса).

Рабочий процесс: Импортируйте OpenAPI-спецификации Stripe и Adyen в Postman → создайте среду с тестовыми ключами → напишите тесты для каждого эндпоинта, который хотите проверить. Postman особенно полезен для тестирования аутентификации и обнаружения ошибок BOLA — вы можете быстро заменить payment_intent_id в запросе и наблюдать за ответом.

5.3. Кастомный фуззер на Python​

Когда готовых инструментов недостаточно, Python — ваш лучший друг. curl_cffi имитирует TLS-отпечатки браузера, а aiohttp обрабатывает тысячи запросов асинхронно.

Базовый фуззер для тестирования race condition при подтверждении платежа:

import asyncio
import aiohttp
import time

async def confirm_payment(session, payment_intent_id, client_secret):
    url = f"[URL]https://api.stripe.com/v1/payment_intents/[/URL]{payment_intent_id}/confirm"
    headers = {"Authorization": "Bearer sk_test_..."}
    data = {"client_secret": client_secret}
    async with session.post(url, headers=headers, data=data) as response:
        return await response.json()

async def race_condition_test():
    async with aiohttp.ClientSession() as session:
        tasks = [confirm_payment(session, "pi_123", "secret_123") for _ in range(5)]
        start = time.time()
        results = await asyncio.gather(*tasks)
        duration = time.time() - start
        print(f"Completed {len(results)} requests in {duration:.2f} seconds")
        print(f"Unique payment_intent IDs: {set(r.get('id') for r in results)}")

asyncio.run(race_condition_test())

Фуззер для тестирования подписи вебхуков Stripe (CVE-2024-41432):

import hmac
import hashlib
import json
import requests

def forge_stripe_webhook(webhook_url, amount):
    payload = {
        "id": "evt_fake123",
        "type": "checkout.session.completed",
        "data": {"object": {"id": "cs_fake", "amount_total": amount, "payment_status": "paid"}}
    }
    body = json.dumps(payload)
    secret = ""
    signature = hmac.new(secret.encode(), body.encode(), hashlib.sha256).hexdigest()
    headers = {"Stripe-Signature": f"t={int(time.time())},v1={signature}"}
    response = requests.post(webhook_url, data=body, headers=headers)
    print(response.status_code, response.text)

5.4. Локальное тестирование вебхуков​

Для безопасного тестирования вебхуков в изолированной среде используйте:

• Stripe CLI — stripe listen --forward-to localhost:3000/webhooks перенаправляет реальные события Stripe на локальный сервер разработки.
• Webhook Relay или Hookdeck — туннелирование локальных вебхуков в интернет для тестирования с Stripe.
• Hookdeck CLI — hookdeck listen 3000 stripe создает общедоступный URL, перенаправляющий локальный вебхук-эндпоинт.
• Adyen Test Webhooks — панель управления Adyen позволяет вручную отправлять тестовые вебхуки (AUTHORISATION, CAPTURE, REFUND) для проверки логики.

5.5. Инструменты тестирования соответствия стандартам (2026)​

• OWASP API Security — коллекция ресурсов для разработчиков: фреймворки тестирования, библиотеки, статьи и практики безопасного проектирования API.
• PCI DSS v4.0 — требует ежегодного пентеста систем, обрабатывающих данные держателей карт (требования 11.3.1, 11.3.2, 11.3.4).
• DORA (EU) — включает явные требования к тестированию на проникновение под руководством угроз (Threat‑Led Penetration Testing) с 2025 года. DORA также внедряет стандарт TIBER-EU.
• EBA ICT Risk Guidelines — устанавливают требования к пентесту для финансовых институтов.
• ISO 27001 — рекомендует регулярное тестирование безопасности и проверку API.

5.6. Интеграция тестирования в CI/CD (Shift Left)​

Для современных команд безопасности критически важно интегрировать пентест API в конвейер CI/CD. Используйте Postman CLI или Newman для автоматического запуска тестов API при каждом развертывании. Burp Suite Professional поддерживает API-сканеры в режиме командной строки, которые можно легко интегрировать в Jenkins.

Часть 6. Юридические рамки: разрешение, bug bounty и комплаенс​

6.1. Разрешение на тестирование​

Пентест платежного шлюза без явного разрешения владельца системы — это компьютерное преступление. Требования документируются через:

• Letter of Authorization — подписанный документ от владельца цели с указанием объема, периода и цели тестирования.
• Rule of Engagement (RoE) — определяет методы тестирования (допустим ли социальный инжиниринг), IP-диапазоны и процедуры эскалации.
• Nondisclosure Agreement (NDA) — обязательство не разглашать информацию, обнаруженную в ходе теста.

Руководства OWASP WSTG подчеркивают необходимость получения письменного разрешения перед сканированием, интерцепцией трафика или автоматизированными атаками.

6.2. Законодательные требования к пентесту (2026 год)​

Регуляторы во всем мире предъявляют строгие требования к тестированию финансовых систем на проникновение. Многие из них со временем становятся обязательными:

• PCI DSS v4.0 — явно требует пентеста для систем, обрабатывающих данные держателей карт. Требование 11.3 (разделы 11.3.1 и 11.3.2) требует ежегодного тестирования и тестирования после значительных изменений. Требование 11.3.4 специально касается веб-приложений для проверки сегментации и выявления таких уязвимостей, как SQL-инъекции и XSS.
• GLBA Safeguards Rule (США) — требует от финансовых институтов ежегодного пентеста или непрерывного мониторинга для защиты NPI. Это обязательство, а не рекомендация.
• GDPR — требует «соответствующих технических и организационных мер». Хотя пентест не назван явно, Recital 49 и DPIAs подразумевают тестирование для высокорисковых веб-приложений.
• PSD2 (Европа) — обязывает к соблюдению SCA и динамической привязки для платежных API.
• DORA (ЕС) — пентест управляется угрозами (TLPT) и обязателен для крупных финансовых организаций с января 2025 года. DORA требует тестирования на основе моделей угроз и реализует стандарт TIBER-EU.

6.3. Bug Bounty программы платежных шлюзов​

Крупные платежные процессоры поощряют этичный поиск уязвимостей через официальные bug bounty программы, многие из которых управляются платформами HackerOne.

Stripe управляет собственной bug bounty программой. Конфиденциальный характер их внутренней инфраструктуры означает, что детали обычно не разглашаются, но награды достигают $20 000 за критические уязвимости (RCE, SQLi, XSS).

Adyen публикует свою политику ответственного раскрытия, но не управляет публичной bug bounty программой. Они приветствуют сообщения о проблемах безопасности через официальный канал, но выплаты ограничены усмотрением Adyen. Разглашение должно быть ответственным.

Правила участия:

• Соблюдайте объем. Stripe и Adyen используют строгие правила bug bounty, защищающие живых пользователей. Тестирование платежных форм или вебхуков без разрешения запрещено.
• Используйте тестовые среды. Stripe предоставляет тестовые ключи и номера карт (например, 4242 4242 4242 4242 с любыми данными CVV/срока действия), Adyen — тестовые учетные записи, которые не списывают реальные средства.
• Не тестируйте живые аккаунты клиентов. Все тесты проводятся на подконтрольных мерчант-аккаунтах.
• Сообщайте о найденном через официальный канал. Stripe требует отправки отчета через HackerOne для рассмотрения.
• Ожидайте скоринга. Stripe оценивает уязвимости на основе CVSS v3.1, включая требование аутентификации и потенциальный ущерб.

Часть 7. Итоговый чек‑лист для white‑hat пентеста платежного шлюза​

Подготовка и объем:

• Получено письменное разрешение (Letter of Authorization) с четким определением объема и периода тестирования.
• Созданы тестовые мерчант-аккаунты в Stripe и Adyen.
• Настроена локальная среда разработки, воспроизводящая интеграцию платежного шлюза (использование Stripe CLI для пересылки вебхуков).
• Определены эндпоинты API в объеме: создание платежей, вебхук-нотификации, OAuth-потоки, административные функции.

Тестирование API и бизнес-логики:

• Запущен Burp Suite для перехвата и модификации всех запросов к API Stripe/Adyen.
• Проведено тестирование BOLA: все ID объектов (customer, payment_intent, subscription) подменены.
• Проверена авторизация на уровне функций (BFLS): административные функции вызываются от обычного аккаунта.
• Выполнено тестирование race condition: параллельные запросы на подтверждение платежа отправлены с помощью Intruder/custom fuzzer.
• Проверена реализация идемпотентности: одинаковые Idempotency-Key отправлены в близкие моменты времени.
• Протестировано OAuth 2.0: проверена защита от CSRF с использованием параметра state и безопасное хранение токенов без утечек в логах.
• Проверено соответствие PSD2: тестирование SCA, динамической привязки и mTLS для Open Banking API.

Тестирование вебхуков:

• Проверена подпись вебхуков Stripe: обработчик отклоняет запросы с неверной подписью; StripeWebhookSecret не пуст.
• Проверено, что событие checkout.session.completed обрабатывается только при payment_status == "paid".
• Проверена обработка отложенных событий (async_payment_succeeded, async_payment_failed), если они релевантны.
• Выполнено тестирование кросс-гейтвейной эксплуатации: поддельный вебхук Stripe для заказа, созданного через другой шлюз.
• Проверена HMAC-подпись вебхуков Adyen с использованием OAuth 2.0 для аутентификации.
• Проверены конечные точки вебхуков на уязвимость к DoS (отправка множества запросов для вызова повторных отправок Stripe).

Инструменты и автоматизация:

• Использован Burp Suite Professional для тестирования BOLA (Intruder) и Repeater для ручного анализа.
• Импортирована спецификация OpenAPI в Postman; написаны автоматические тесты для всех критических потоков.
• Написан пользовательский фуззер на Python для тестирования race condition, подделки вебхуков и перебора параметров.
• Тестирование вебхуков выполнено с помощью Stripe CLI и Hookdeck.

Отчетность и ремедиация:

• Подготовлен отчет, детализирующий каждую уязвимость с указанием доказательств (скриншоты, логи, curl‑команды).
• Уязвимости классифицированы по стандарту CVSS v3.1; критичность оценена для каждой.
• Предложены воспроизводимые шаги для исправления (с четкими инструкциями по коду).
• Информация о раскрытии предоставлена ограниченному кругу: только лицу, уполномоченному на ремедиацию.
• Все тестовые данные очищены после завершения пентеста.

Заключение: мастерство и ответственность​

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

Три главных вывода этой статьи:

1. Платежные API требуют особого подхода к тестированию. Стандартных сканеров недостаточно. Необходимо тестирование соответствия PSD2/Open Banking, поиск race condition в потоках платежей и безопасность вебхук-коммуникаций.
2. Автоматизация ускоряет, но не заменяет экспертизу. Burp Suite, Postman и Python могут отправлять тысячи запросов, но только человек может интерпретировать результаты и понять бизнес-контекст уязвимости.
3. Разрешение — это не формальность. Оно защищает и пентестера, и владельца цели от юридических последствий. Работа в рамках bug bounty программы упрощает процесс и дает возможность ответственно раскрыть информацию.

Грамотный специалист по безопасности знает, что мастерство — это не только умение взламывать, но и умение делать это ответственно.

Быстрая памятка на одну строку:
«API платежей уязвимы к BOLA, race condition, подделке вебхуков и утечкам OAuth-токенов. Burp Suite для перехвата, Python для фаззинга, Postman для автоматизации. Ответственность так же важна, как и мастерство.»