Vulnerabilities
Уязвимость, как-то связанная с POS-терминалом (смогли в QIWI, не зная PIN-кода, сделать операции): https://hackerone.com/reports/890747
Уязвимость при встраивании Apple Pay на сайте и в мобильном приложении. Суть: принимались криптограммы с другого сайта: https://hackerone.com/reports/996540
Ошибки работы с числами
Переполнения чисел
Как пример: 100 и 2**32 + 100 — одно число может быть. (Это может быть использовано не только для работ с числами при платежах, но и в Broken Access Control векторах)
Числа с отрицательным знаком
Округление сумм
Основано на неправильной работе с округлением чисел
Берем маленькую сумму, переводим ее на валютный счет. Банк округляет сумму до сотых в большую сторону, допустим.
Переводим ее обратно, пусть даже с невыгодным курсом
Получаем профит
Работает только на маленьких суммах, с ростом суммы, профит становится отрицательным
Защита:
сделать минимальную сумму перевода, при которой эксплуатация будет иметь отрицательный профит
Выстроить логику не на переводе рублей в доллары, а на покупке долларов за рубли (в этом случае не будет округления)
Добавить комиссию после определенного количества конвертаций
Раскрытие URL для зачисления платежа
Платежная система каким-то образом сообщает сервису, что платеж проведен успешно (у сервиса есть обработчик). Если каким-то путем раскрыть этот обработчик, то тут есть пространство для тестов:
Проверка подписи на стороне сервиса
Проверка параметров на стороне сервиса
Раскрытие URL с валидной подписью
Проверка атрибутов платежа
Ошибки на стороне сервиса:
Проверка суммы платежа
Проверка валюты платежа
Проверка количества товара (0.1 яблока например)
Проверка на изменение адреса и способа доставки (например, для обхода комиссий дополнительных)
Проверка дублирования параметров
Проверка отсутствия обязательных параметров для процесса
Проблемы со сравнением чисел (1e1, 0xFF, ...) и некорректная работа с такими числами, их парсинг
Проблема с типизацией (100, "100") и операциями над этими числами
Refund
Можно ошибиться на любом наборе проверок:
Была ли транзакция успешной, по которой запросили refund
Сумма частичного или полного refund меньше, чем сумма транзакции (сюда же попадают акции и тп)
Это повторный refund
...
Race Condition
Можно попробовать через HTTP Pipelining (в HTTP 1.1)
В HTTP 2 есть свои механизмы
ну или вручную, главное чтобы запросы улетели в короткий интервал (меньше секунды)
Time-of-Check-Time-of-Use (TOCTOU)
Это ошибка, возникающая из-за того, что приложение проверяет условия прежде, чем использовать их. Таким образом, существует время, между окончанием проверки и началом использования, в которое злоумышленник может попытаться изменить состояние (тем самым повлияв на результат проверки)
Transferring Money or Points, or Buying Items Simultaneously
Делаем одно и то же действие дважды в один момент времени (например, из-под разных сессий). Проверку пройдут оба действия (например, дважды начислит на другой счет $100, тк на счету есть $100)
Changing the Order upon Payment Completion
Меняем корзину во время обработки платежа
Changing the Order after Payment Completion
Если приложение не проверяет статус платежа при изменении заказа, это может привести к финансовым потерям
Last updated