Google IAP renvoie un token d'achat court pour vérification

j'ai reçu ces mêmes jetons invalides dans notre application sans aucune idée de la raison depuis un moment. Les tokens sont disponibles dans différents formats, y compris 24 caractères alpha (par ex. glvnqnpjqslcagyimgxeuybk ), 15 chiffres (par ex. 781871156762279 , voir cette question ), et même des jetons de longueur appropriée qui ont un format légèrement différent de ceux valides (par ex. xdavcuvdnniwwrhwemleqjdz.rSQozm... voir cette question ).

ce sont les messages d'erreur que j'ai reçu du in-app billing API pour ces différents tokens à 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

I testé deux applications qui prétendent pirater des achats in-app: Freedom , et Lucky Patcher , sur un appareil enraciné. Le premier n'a pas fonctionné: bien qu'il ait détecté que notre application peut faire des achats, quand j'ai essayé de faire un faux il m'a dit que "les achats de cette application ne peuvent pas être truqués". Le dernier a fait travail après quelques bricolages, cependant, et a généré un jeton d'achat court exactement comme dans la question. Quand j'ai essayé de vérifier jeton via L'API de facturation , j'ai reçu le même message de" jeton invalide " qu'avant.

j'ai aussi commencé à enregistrer l'état racine des dispositifs générant des jetons invalides en utilisant cette méthode . Bien que cela ne soit pas une preuve de quoi que ce soit, le fait que presque tous jetons invalides provenait de dispositifs enracinés m'a fait soupçonner un acte criminel.

l'attaque

je crois que l'attaque fonctionne comme suit. Quelqu'un qui en sait plus à ce sujet, veuillez carillon!

• l'utilisateur installe l'une des applications de piratage qui prétend effectuer des achats gratuits sur un appareil enraciné
• Le piratage application de patchs, la légitime Dans l'Application Service de Facturation sur l'appareil, ou émule
• pendant un flux d'achat l'application de piratage intercepte le achat Intent qui est destiné 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, mais la demande d'achat n'atteint jamais les serveurs de Google
• une application qui s'appuie sur la validation de token local demandera des achats auprès du Service de facturation In-App. Cette demande est également interceptée par l'application de piratage, qui affirme que l'achat est valable 1519190920"
• une application qui s'appuie sur server token validation envoie le token d'achat à un serveur, qui fait un appel à in-app billing API , qui n'a jamais vu le token, et retourne donc une réponse "invalid token

atténuation

• les applications qui s'appuient uniquement sur le service de facturation interne sont vulnérable ! Le achat et le validation de la commande demandes sont à la fois intercepté par la même frauduleuse d'application. Il n'y a pas de défense.
Les applications
• qui s'appuient sur un serveur d'arrière-plan doivent envoyer le jeton d'achat à l'arrière-plan pour être vérifiées par L'API éditeur. Ces applications doivent pas créditer l'utilisateur avec l'achat jusqu'à ce que le backend le vérifie et renvoie un résultat positif à l'application. Le backend doit probablement suivre les recommandations de sécurité pour la facturation In-App. Ces applications sont probablement plus sûr d'achats frauduleux, mais ils génèrent beaucoup d'invalides achats.
• Je ne pense pas qu'il soit sécuritaire de se fier à la longueur ou au format du jeton, de l'id de commande ou d'autres données pour déterminer la validité de l'achat. Ces jetons ne sont probablement mal formés que parce qu'ils émulaient un format précédent. Probablement les auteurs de l'application de piratage va éventuellement publier une version pour émuler tout format que Google se soucie de concevoir. Le seul moyen sûr est de vérifier l'achat via L'API de facturation In-app sur un appareil que vous contrôlez, à savoir: serveur.