> For the complete documentation index, see [llms.txt](https://appsecurity.gitbook.io/offensive/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://appsecurity.gitbook.io/offensive/appsec/technologies/banks-and-payments/vulnerabilities.md). # Vulnerabilities Уязвимость, как-то связанная с POS-терминалом (смогли в QIWI, не зная PIN-кода, сделать операции): Уязвимость при встраивании Apple Pay на сайте и в мобильном приложении. Суть: принимались криптограммы с другого сайта: ## Ошибки работы с числами ### Переполнения чисел Как пример: `100` и `2**32 + 100` — одно число может быть. (Это может быть использовано не только для работ с числами при платежах, но и в Broken Access Control векторах) ### Числа с отрицательным знаком ### Округление сумм Основано на неправильной работе с округлением чисел Берем маленькую сумму, переводим ее на валютный счет. Банк округляет сумму до сотых в большую сторону, допустим. Переводим ее обратно, пусть даже с невыгодным курсом Получаем профит Работает только на маленьких суммах, с ростом суммы, профит становится отрицательным Защита: * сделать минимальную сумму перевода, при которой эксплуатация будет иметь отрицательный профит * Выстроить логику не на переводе рублей в доллары, а на покупке долларов за рубли (в этом случае не будет округления) * Добавить комиссию после определенного количества конвертаций ## Раскрытие URL для зачисления платежа Платежная система каким-то образом сообщает сервису, что платеж проведен успешно (у сервиса есть обработчик). Если каким-то путем раскрыть этот обработчик, то тут есть пространство для тестов: * Проверка подписи на стороне сервиса * Проверка параметров на стороне сервиса * Раскрытие URL с валидной подписью * [Length Extension Attack](https://appsecurity.gitbook.io/binary/v/crypto/khesh-funkcii/mac/attacks/sha1-mac-length-extension-attack) ## Проверка атрибутов платежа Ошибки на стороне сервиса: * Проверка суммы платежа * Проверка валюты платежа * Проверка количества товара (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 Если приложение не проверяет статус платежа при изменении заказа, это может привести к финансовым потерям