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

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

Чтобы упростить понимание, я создал на Laravel фиктивное приложение, которое позволяет пользователям совершать платежи с использованием как Paystack Inline, так и Paystack Standard. Проще говоря, Paystack Inline позволяет пользователям совершать платежи, не покидая ваш сайт, в то время как Paystack Standard просто перенаправляет пользователей обратно на ваш сайт после того, как платежи были произведены через Paystack. Стандарт был создан с использованием пакета paystack Prosper Otemuyiwa для Laravel, в то время как встроенный был создан путем встраивания js-кода paystack в наш код. Ссылка на репозиторий GitHub этого фиктивного приложения доступна в конце этой статьи.

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

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

Уязвимости интеграции встроенных платежей

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

Я нажал на кнопку «Пополнить свой счет» с помощью встроенного метода. После щелчка было показано всплывающее окно стека платежей, в котором можно было ввести данные карты и отправить запрос на обработку платежа. На этом этапе, поскольку не было перехвата для отправки запроса на сервер, я предположил, что приложение ожидает полной обработки платежа, прежде чем отправлять какие-либо данные на сервер. Я производил платежи и ждал перехвата.

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

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

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

Давайте посмотрим, сможем ли мы отправить один и тот же запрос Ajax несколько раз на сервер в репитере отрыжки.

Да, я могу!!. Ответ возвращает 200 ok, что означает, что запрос был успешно обработан. Деньги также отразились на моем счете. Это еще одна уязвимость. Разработчик полагал, что этот запрос будет отправлен только в случае успешной оплаты. Бэкэнд должен иметь возможность делать такие запросы единовременно, независимо от интерфейса. Последующие запросы следует рассматривать как недействительные.

Уязвимости стандартной платежной интеграции

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

Хм, эта реализация явно отличается от первой. Запрос отправляется на сервер, прежде чем я буду перенаправлен на страницу стека платежей для совершения платежей. Что это за ссылка и жетон? Позвольте мне просто отправить их на ретранслятор на случай, если они мне понадобятся позже. Разрешите также изменить этот платеж с 5000 на 10000. Что происходит?

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

Подожди, это все, на что я потратил 10 000 найр? Ничего особенного в этом запросе. Просто некоторые параметры ссылки на URL-адресе. Позвольте мне отправить ретранслятор и сравнить с исходным, которое я отправил, прежде чем я потерял сознание. Хлопнуть!!. Существует сходство, справочные данные, отправленные ранее на сервер, совпадают с данными, добавленными в качестве параметра для этого обратного вызова приложения. Было бы возможно, если я запрошу оплату, сохраню отправленную ссылку и сделаю вид, что это paystack, отправив запрос на тот же URL-адрес обратного вызова с тем же параметром, который отправит paystack. Дай мне попробовать и посмотреть.

Хлопнуть!! Оно работает. Разработчик предположил, что только Paystack будет отправлять запросы на этот URL-адрес обратного вызова. Я думаю, что это та же уязвимость, что и для inline. Вы не можете контролировать запросы, отправленные пользователем.

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

Тоже работает !!. Это означает, что нет формы проверки повторяющихся запросов.

Возможные решения

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

Другое решение, которое было бы более эффективным, - это когда провайдеры платежей заставляют приложения отправлять ответ 200 ok с сервера приложений перед перенаправлением пользователей на URL-адрес обратного вызова или обработкой обратных вызовов.

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

Вот ссылка на репозиторий github для фиктивного проекта https://github.com/akandeBolaji/bug-finder/tree/vulnerability001

Не стесняйтесь оставлять комментарии и делиться безопасными способами обработки платежей.