Обращение к разработчикам.
Я реализую обработку кредитных карт в мобильных приложениях для iOS (Swift) и Android (Kotlin) с использованием собственного SDK (уровень соответствия SAQ A EP)
Мы подумали:
- отключение буфера обмена для поля CC
- отключение отслеживания для добавления экранов CC
- разыменование объекта, как только экраны закрываются
Для iOS мы убедились, что до тех пор, пока класс разыменовывается, память, выделенная с помощью CC-информации, там больше не видна (новый объект занял ее)
Для Android мы не будем использовать неизменяемые типы, т.е.Строка для хранения CC, а не массив примитивных символов, но не уверен, как это применимо к Kotlin, это то же самое?
Мы бы хотели, чтобы данные CC были как можно короче в памяти и отбрасывали их (сделатьуверен, что его уже нет), как только он нам не понадобится.
В любом случае, любые советы по безопасному обращению с этим / лучшие практики для обеих платформ (iOS, Android) были бы хорошими.
В качестве бонуса неплохо было бы использовать сценарии атаки, если не реализовывать такую защиту, то есть загружать модуль ядра для выгрузки ОЗУ на Android или память процесса (если это возможно), выгрузку ОЗУ через ADB, gdb и т. Д. В iOS я не могу думать олюбой, кроме сброса физического ОЗУ путем открытия телефона.
Спасибо,
Обновление 1:
Я постараюсь получить ответ от поставщиков, почему онииспользуйте объекты вместо примитивов и, возможно, обнуляйте их после использования.
Несколько случайных продавцов:
Braintree
https://github.com/braintree/braintree_android/blob/cb401acd503c8cf818e3fed5f2dcf9ab252ebaa8/Braintree/src/main/java/com/braintreepayments/api/models/CardBuilder.java
PayU, и они также используют объекты- Hashmap.
Еще один целочисленный класс mpay24
https://github.com/mpay24/mpay24-java/blob/master/src/main/java/com/mpay24/payment/data/PaymentType.java
Может быть, в конце нет возможности уйти без объекта в этой среде ООП, поэтому не делаетсмысл использовать примитивы по пути?Или они все делают неправильно.Также нужно будет отладить его / исследовать его подробнее.