Доброго времени суток.
Что имеем. Бэк - nodejs, Front - Vuejs.
Задача: Подтверждать успешные транзакции пользователей на nodejs сервере.
Собственно пред история.
У нас есть клиент-серверное приложение, мини магазинчик косметики и различных товаров для дома.
Фронт написан на vuejs.
Аутентификация / авторизация клиента с помощью JWT токена Passport.js.
Собственно по части оплаты подтверждения платежей мы прокололись. Нас взломали и непонятно каким образом научились пополнять себе баланс, в ЛК имеется вывод части средств при покупки от N-суммы.
Как всё было устроено.
На Фронте человек в ЛК заходил в пункт пополнить счёт, выбирал платёжную систему. После оплаты, шёл оплачивать.
В данный момент на бэке создавалась запись в БД c полями status - false и summ - N. ID транзакции.
Транзакции подтверждались через API платёжки, каждую минуту работал крон. и сверял по ID транзакции оплачена ли она, и не истёк ли срок действия. Если API отдавал true по полю success, то транзакция закрывалась, и пользователю начислялся баланс.
Вот этот весь алгоритм оказался уязвимым, и был скомпрометирован.
Собственно вопрос, как и с помощью каких инструментов реализовать это в более-менее безопасном виде.
Такой момент - единственное что удалось выяснить что уязвимость использовалась без front-end. Т.е только при наличии бэка, и скорее всего базу не ломали.
Первые действия которые приходят на ум, подключить шифрование к передаваемым данным пользователя с фронта.
Реализовать некий механизм хранения SC в куках пользователя, и только при его наличии создавать транзакцию.
Опять же при проверки транзакции имея только поля от API success expired, что можно придумать?
ex Software Engineer at Reddit TS/React/GraphQL/Go
вообще платежка должна слать уведомление (дёргать твой АПИ) при успешности или наоборот при отказе транзакции. Трафик должен быть или подписан ключем или проверяться на входной IP адрес
jamster, ну так тоже самое, платеж создали, затем проверяете раз в 5-10 секунд статус до тех пор пока он не поменяется, как поменялся, сразу меняете в базе транзакционно все это дело. Общение по https чтобы mitm не проканал
jamster, значит заказывай аудит кода, потому что это стандартная рабочая архитектура, тут нечего ломать, если залатаны все дыры (проверки, отдельные эндпоинты и так далее)
Прям ответа дать не могу, но могу поделиться некоторыми соображениями:
1. Уйти от использования Passport.js, написать своё решение, так как использование стандартных модулей для авторизации уже само по себе не безопасно.
2. Вы же логируете все действия пользователей, которые связаны с финансами?
3. Данные от пользователя валидируются на стороне бакенда, при создании пополнения?
4. Задайте себе вопрос, вы уверены в своей платёжной системе?
5. Возможно у кого то есть доступ к БД
Спасибо уже ближе к делу.
1. Рассмотрю.
2. Да, в логах ничего необычного.
3. Нет, но в записях транзакций пока не возникает вопросов.
4. Здесь да, потому-что она работает и на других сервисах - как часы.
5. Нет, потому-что трогали только эту часть.
Вообще левые пополнения на счёт шли каждые 30 секунд, минуту. иногда больше.
Т.е как будто кто-то кроном своим запросы слал, не сильно похоже на человека.
Судя по всему, программист, который писал шлюз оплаты оставил пасхалочку и теперь умело ею пользуется. В вашей схеме всё в порядке. Если не знаешь ID платежки, то ничего не получишь. Ищите каким образом инсайдер получает ID платежки. Кстати, этот программист может продолжать работать у вас, тогда смотрите, у кого доступ в СУБД.
Средний
