Google IAP renvoie un jeton d'achat réduit pour vérification
J'ai implémenté des jetons d'achat Google IAP de vérification côté serveur. Mon application mobile m'envoie ce jeton comme il se doit depuis Google.
Un jeton régulier ressemble à
minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD
mais parfois je reçois un jeton court comme celui-ci
korpimulxmslxissnschtkdb
Lorsque je vérifie ce jeton à l’aide de l’API des développeurs Google Play: https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token , j’obtiens un Erreur 404.
Où est le problème? Est-il possible que ce jeton court représente des transactions réelles?
J'ai reçu ces mêmes jetons invalides dans notre application sans aucune idée de la raison pendant un certain temps. Les jetons sont disponibles dans différents formats, y compris 24 caractères alphabétiques (par exemple, glvnqnpjqslcagyimgxeuybk), 15 chiffres (par exemple, 781871156762279, voir cette question ), et même des jetons de longueur appropriée dont le format est légèrement différent de celui en vigueur. ceux-ci (par exemple, xdavcuvdnniwwrhwemleqjdz.rSQozm...voir cette question ).
Voici les messages d'erreur que j'ai reçus de la API de facturation intégrée pour ces différents jetons à un moment ou à un autre:
"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."
La réponse donnée par Marc Greenstock m'a donné une idée pour essayer de reproduire le problème.
Faire un achat frauduleux
J'ai testé deux applications qui prétendent pirater des achats intégrés: Freedom et Lucky Patcher, sur un appareil enraciné. Le premier ne fonctionnait pas: bien qu'il ait détecté que notre application puisse faire des achats, lorsque j'ai essayé d'en fabriquer un faux, il m'a dit que "les achats de cette application ne peuvent pas être falsifiés". Ce dernier a cependant travaillé après quelques manipulations et a généré un jeton d’achat court exactement comme dans la question. Lorsque j'ai essayé de vérifier le jeton via API de facturation intégrée , j'ai reçu le même message exact "jeton non valide" qu'auparavant.
J'ai également commencé à consigner l'état racine des périphériques générant des jetons non valides à l'aide de cette méthode . Bien que cela ne soit la preuve de rien, le fait que presque tous les jetons non valides provenaient de périphériques enracinés me faisait penser à un acte criminel.
L'attaque
Je crois que l'attaque fonctionne comme suit. Quiconque en sait plus à ce sujet s'il vous plaît carillon dans!
- L'utilisateur installe l'une des applications de piratage prétendant effectuer des achats intégrés gratuits sur un appareil root
- L’application de piratage corrige le service de facturation in-app légitime sur le terminal ou l’émule
- Au cours d’un processus d’achat, l’application de piratage intercepte le achat
Intentdestiné au service légitime. - L'application de piratage traite la demande d'achat et génère une réponse de la même manière que le service légitime le ferait, mais la demande d'achat n'atteindra jamais les serveurs de Google.
- Une application qui s'appuie sur la validation de jeton local demandera des achats au service de facturation intégré. Cette demande est également interceptée par l'application de piratage, qui prétend que l'achat est valide
- Une application qui s'appuie sur la validation du jeton serveur envoie le jeton d'achat à un serveur, lequel appelle la API de facturation intégrée à l'application , qui n'a jamais vu le jeton et renvoie par conséquent un " jeton invalide "réponse
Atténuation
- Les applications qui reposent uniquement sur le service de facturation intégré sont vulnérables! Les demandes achat et achat sont toutes deux interceptées par la même application frauduleuse. Il n'y a pas de défense.
- Les applications qui reposent sur un serveur dorsal doivent envoyer le jeton d'achat au serveur afin qu'il soit vérifié via l'API de l'éditeur. Ces applications doivent pas créditer l'utilisateur de l'achat jusqu'à ce que le serveur le vérifie et renvoie un résultat positif à l'application. Le backend devrait probablement suivre les recommandations de sécurité pour la facturation In-App. Ces applications sont probablement plus sûres des achats frauduleux, même si elles génèrent de nombreux achats non valides.
- Je ne pense pas qu'il soit sûr de compter sur la longueur ou le format du jeton, de l'identifiant de la commande ou d'autres données pour déterminer la validité de l'achat. Ces jetons sont probablement uniquement malformés car ils émulaient un format précédent. Vraisemblablement, les auteurs de l'application de piratage publieront une version pour imiter tous les formats imaginables par Google. Le seul moyen sûr est de vérifier l'achat via l'API de facturation intégrée à l'application sur un appareil que vous contrôlez, c'est-à-dire. un serveur.
Avez-vous fini par résoudre ceci?
La seule raison pour laquelle je peux suggérer est que le jeton a été généré par un Cracker d'achat intégré, tel que l'application "Achats intégrés Freedom pour Android", qui peut être installé sur des appareils enracinés.
Je suis intéressé de voir si vous avez reçu un jeton court pour tout achat test que vous avez effectué vous-même.
Une autre indication que le jeton est faux est le format de orderId obtenu après l'achat sur l'application.
S'il ne respecte pas le format indiqué dans Administration de la facturation in-app docs, il s'agit probablement d'un achat frauduleux.
J'ai trouvé une solution partielle qui fonctionne avec certains faux fournisseurs IAP: revérifier la signature numérique manuellement. Quel que soit le simulateur IAP, il ne dispose pas d'une copie de la clé RSA privée de Google. J'ai fait mon propre chèque de signature, et il attrape au moins certaines de ces fausses transactions.