Ответ 1
Я получаю эти же недействительные токены в нашем приложении, не подозревая причину на некоторое время. Токены поступают в различных форматах, включая 24 альфа-символа (например, glvnqnpjqslcagyimgxeuybk), 15 цифр (например, 781871156762279, см. Этот вопрос) и даже токены надлежащей длины, которые имеют несколько иной формат от действительных (например, xdavcuvdnniwwrhwemleqjdz.rSQozm... см. этот вопрос).
Это сообщения об ошибках, которые я получил от API выставления счетов в приложении для этих разных токенов в тот или иной момент:
-
"code": 404, "message": "The purchase token was not found." -
"code": 400, "message": "Invalid Value" -
"code": 400, "message": "Your request is invalid for this subscription purchase."
Ответ, данный Марком Гринстоком, дал мне идею попытаться воспроизвести проблему.
Создание мошеннической покупки
Я тестировал два приложения, которые заявляют, что взломали покупки в приложениях: Свобода и Lucky Patcher на корневом устройстве. Первый не работал: хотя он обнаружил, что наше приложение может совершать покупки, когда я пытался сделать поддельный, он сказал мне, что "это приложение не может быть подделано". Тем не менее, последний работал после некоторого ворчания и создал короткий токен покупки точно так же, как и в вопросе. Когда я попытался проверить токен с помощью API фактурирования в приложении, я получил то же самое "неверное токеновое сообщение", как и раньше.
Я также начал регистрировать корневой статус устройств, генерирующих недопустимые токены, используя этот метод. Хотя это не доказательство чего-либо, тот факт, что почти все недействительные токены возникли из корневых устройств, заставило меня подозревать, что нечестная игра.
Атака
Я считаю, что атака работает следующим образом. Любой, кто знает об этом, пожалуйста, звоните!
- Пользователь устанавливает одно из приложений для взлома, которое утверждает, что делает бесплатные покупки в приложении на корневом устройстве.
- Приложение для взлома либо исправляет законную In-App Billing Service на устройстве, либо эмулирует его.
- В процессе покупки приложение взлома перехватывает покупку
Intent, которая предназначена для законной службы - Приложение для взлома обрабатывает запрос на покупку и генерирует ответ таким же образом, как и законная услуга, но запрос на покупку никогда не доходит до серверов Google.
- Приложение, основанное на проверке локального токена, будет запрашивать покупки у службы биллинга In-App. Этот запрос также перехвачен приложением взлома, в котором утверждается, что покупка действительна.
- Приложение, основанное на проверке маркера сервера, отправляет токен покупки на сервер, что делает вызов API фактурирования в приложении, который никогда не видел токена и поэтому возвращает ответ "недействительный токен"
Смягчение
- Приложения, которые полагаются исключительно на службу биллинга In-App, уязвимы! Запросы на покупку и подтверждение покупки перехватываются одним и тем же мошенническим приложением. Нет защиты.
- Приложения, которые полагаются на серверный сервер, должны отправить токен покупки на сервер, который будет проверен через API издателя. Эти приложения должны не кредитовать пользователя при покупке до тех пор, пока бэкэнд не проверит его и не вернет положительный результат в приложение. Бэкэнд должен, вероятно, следовать рекомендациям рекомендаций по In-App Billing. Эти приложения, вероятно, более безопасны из-за мошеннических покупок, хотя они генерируют много недействительных покупок.
- Я не думаю, что безопасно полагаться на длину или формат токена, идентификатор заказа или другие данные для определения действительности покупки. Эти жетоны, вероятно, только искажены, потому что они имитировали предыдущий формат. Предположительно, авторы приложения для взлома в конечном итоге выпустят версию для подражания любому формату, который Google хочет разработать. Единственным безопасным средством является проверка покупки через API выставления счетов в приложении на устройстве, которое вы контролируете, т.е. сервер.