Google IAP возвращает короткий токен покупки для проверки

Я внедрил проверки на покупку на стороне сервера Google IAP. Мое мобильное приложение отправляет мне этот токен, чтобы получить его от Google.

Регулярный токен выглядит

minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD

Но иногда я получаю короткий токен, подобный этому

korpimulxmslxissnschtkdb

Когда я проверяю этот токен с помощью API разработчика Google Play: https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token , для короткого токена я получаю ошибку 404.

В чем проблема? Возможно ли, что этот короткий токен представляет собой реальные транзакции?

Solutions Collecting From Web of "Google IAP возвращает короткий токен покупки для проверки"

Я получаю эти же недействительные токены в нашем приложении, не подозревая причину на некоторое время. Токены поступают в различных форматах, в том числе 24 альфа-символа (например, glvnqnpjqslcagyimgxeuybk ), 15 цифр (например, 781871156762279 , см. Этот вопрос ) и даже 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."

Ответ Марка Гринстока дал мне идею попытаться воспроизвести проблему.

Создание мошеннической покупки

Я тестировал два приложения, которые утверждают, что взломали покупки в приложении: Freedom и Lucky Patcher , на корневом устройстве. Первый не работал: хотя он обнаружил, что наше приложение может совершать покупки, когда я пытался сделать поддельный, он сказал мне, что «покупки этого приложения нельзя подделать». Тем не менее, последний работал после некоторого ворчания и создал короткий токен покупки точно так же, как и в вопросе. Когда я попытался проверить токен через API биллинга в приложении , я получил то же самое «неверное токен», как и раньше.

Я также начал регистрировать корневой статус устройств, генерирующих недействительные токены, используя этот метод . Хотя это ничего не доказывает, тот факт, что почти все недействительные токены возникли из корневых устройств, заставило меня заподозрить в нечестной игре.

Атака

Я считаю, что атака работает следующим образом. Любой, кто знает об этом, звоните!

  • Пользователь устанавливает одно из приложений для взлома, которые заявляют, что совершают бесплатные покупки в приложении на корневом устройстве
  • Приложение для взлома либо исправляет законную In-App Billing Service на устройстве, либо эмулирует его
  • В процессе покупки приложение взлома перехватывает Intent покупки , предназначенное для законной службы
  • Приложение-хакер обрабатывает запрос на покупку и генерирует ответ так же, как и законная услуга, но запрос на покупку никогда не доходит до серверов Google
  • Приложение, основанное на проверке локального токена, запрашивает покупки у службы биллинга In-App. Этот запрос также перехвачен приложением взлома, в котором утверждается, что покупка действительна
  • Приложение, основанное на проверке маркера сервера, отправляет токен покупки на сервер, что делает вызов API-интерфейса биллинга в приложении , который никогда не видел токена и поэтому возвращает ответ «неверный токен»

смягчение

  • Приложения, которые полагаются исключительно на службу биллинга In-App, уязвимы ! Запросы на покупку и проверку покупки перехватываются одним и тем же мошенническим приложением. Нет защиты.
  • Приложения, которые полагаются на серверный сервер, должны отправить токен покупки на сервер, который будет проверен через API издателя. Эти приложения не должны кредитовать пользователя при покупке, пока бэкэнд не проверит его и не вернет положительный результат в приложение. Бэкэнд должен, вероятно, следовать рекомендациям по безопасности для In-App Billing. Эти приложения, вероятно, более безопасны из-за мошеннических покупок, хотя они генерируют много недействительных покупок.
  • Я не думаю, что безопасно полагаться на длину или формат токена, идентификатор заказа или другие данные для определения действительности покупки. Эти жетоны, вероятно, только искажены, потому что они имитировали предыдущий формат. Предположительно, авторы взломанного приложения в конечном итоге выпустят версию для эмуляции любого формата, который Google заботится о разработке. Единственным безопасным средством является проверка покупки через API выставления счетов в приложении на устройстве, которое вы контролируете, т.е. Сервер.

Вы в конечном итоге решили это?

Единственная причина, по которой я могу предположить, заключается в том, что токен был создан приложением для покупок в приложении, например, приложение «Свобода в приложении для Android», которое может быть установлено на корневых устройствах.

Мне интересно узнать, получили ли вы короткий токен для любых пробных покупок, которые вы сделали сами.

Еще одним признаком того, что токен является поддельным, является формат orderId, который вы получаете после покупки в приложении.

Если он не соответствует формату, указанному в документах администрирования In-app Billing , скорее всего, это мошенническая покупка.