android - studio - Google IAP devuelve el token de compra corta para verificación

in app purchase android studio (3)

He implementado la verificación de servidor tokens de compra de Google IAP. Mi aplicación móvil me envía este token para obtenerlo de Google.

Un token regular parece

minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD

pero a veces me sale un token corto como este

korpimulxmslxissnschtkdb

Cuando verifico este token a través de la API de Google Play Developer: https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token , para el token corto recibo un error 404.

¿Dónde está el problema? ¿Es posible que este token corto represente transacciones reales?

¿Terminaste resolviendo esto?

La única razón por la que puedo sugerir es que el token fue generado por un Cracker de compras integrado en la aplicación como la aplicación "Compras desde Android de la aplicación de Freedom" que se puede instalar en dispositivos rooteados.

Me interesa ver si ha recibido un token corto para cualquier compra de prueba que haya realizado usted mismo.

Otra indicación de que el token es falso es el formato del orderId que se obtiene después de la compra en la aplicación.

Si no sigue el formato indicado en la sección Administración de documentos de facturación en la aplicación , lo más probable es que sea una compra fraudulenta.

He encontrado una mitigación parcial que funciona con algunos proveedores de IAP falsos: vuelva a verificar la firma digital manualmente. Independientemente de lo que haga el simulador IAP, no tienen una copia de la clave RSA privada de Google. Hice mi propio cheque de firma, y captura al menos algunas de esas transacciones falsas.

El código de verificación es una esencia.

He estado recibiendo estos mismos tokens no válidos en nuestra aplicación sin tener idea de la razón por un tiempo. Los tokens vienen en varios formatos, incluyendo 24 caracteres alfa (por ejemplo, glvnqnpjqslcagyimgxeuybk ), 15 dígitos (por ejemplo, 781871156762279 , vea esta pregunta ), e incluso tokens de longitud adecuada que tienen un formato ligeramente diferente al de los válidos (por ejemplo, xdavcuvdnniwwrhwemleqjdz.rSQozm... ver esta pregunta ).

Estos son los mensajes de error que he recibido de la API de facturación en la aplicación para estos distintos tokens en un momento u otro:

"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 respuesta dada por Marc Greenstock me dio una idea para tratar de reproducir el problema.

Haciendo una compra fraudulenta

Probé dos aplicaciones que afirman piratear compras dentro de la aplicación: Freedom y Lucky Patcher , en un dispositivo rooteado. El primero no funcionó: aunque detectó que nuestra aplicación puede hacer compras, cuando intenté hacer una falsa, me dijo que "las compras de esta aplicación no pueden ser falsificadas". Sin embargo, el último funcionó después de algunos problemas y generó una ficha de compra corta exactamente como en la pregunta. Cuando intenté verificar el token a través de la API de facturación en la aplicación , recibí el mismo mensaje exacto de "token no válido" que antes.

También comencé a registrar el estado raíz de los dispositivos que generan tokens no válidos utilizando este método . Si bien esto no es una prueba de nada, el hecho de que casi todos los tokens no válidos se originaron en dispositivos rooteados me hizo sospechar de un juego sucio.

El ataque

Creo que el ataque funciona de la siguiente manera. Cualquiera que sepa más sobre esto, por favor, ¡entra!

El usuario instala una de las aplicaciones de piratería que pretende realizar compras gratuitas dentro de la aplicación en un dispositivo rooteado.
La aplicación de piratería o parches el servicio de facturación en la aplicación legítima en el dispositivo, o la emula
Durante un flujo de compra, la aplicación de pirateo intercepta el Intent compra que está destinado al servicio legítimo.
La aplicación de piratería procesa la solicitud de compra y genera una respuesta de la misma manera que lo haría el servicio legítimo, pero la solicitud de compra nunca llega a los servidores de Google.
Una aplicación que se basa en la validación de token local solicitará compras del Servicio de facturación en la aplicación. Esta solicitud también es interceptada por la aplicación de piratería, que afirma que la compra es válida.
Una aplicación que se basa en la validación del token del servidor envía el token de compra a un servidor, que realiza una llamada a la API de facturación en la aplicación , que nunca ha visto el token, y por lo tanto devuelve una respuesta de "token no válido"

Mitigación

¡Las aplicaciones que se basan exclusivamente en el Servicio de facturación dentro de la aplicación son vulnerables ! Las solicitudes de compra y de validación de compra son interceptadas por la misma aplicación fraudulenta. No hay defensa.
Las aplicaciones que dependen de un servidor backend deben enviar el token de compra al backend para que se verifique a través de la API del editor. Estas aplicaciones no deben acreditar al usuario con la compra hasta que el backend la verifique y devuelva un resultado positivo a la aplicación. El backend probablemente debería seguir las recomendaciones de seguridad para la facturación en la aplicación. Estas aplicaciones son probablemente más seguras contra compras fraudulentas, aunque generan muchas compras inválidas.
No creo que sea seguro confiar en la longitud o el formato del token, la identificación del pedido u otros datos para determinar la validez de la compra. Estas fichas probablemente solo tienen un formato incorrecto porque estaban emulando un formato anterior. Presumiblemente, los autores de la aplicación de piratería finalmente lanzarán una versión para emular cualquier formato que Google quiera diseñar. El único medio seguro es verificar la compra a través de la API de facturación en la aplicación en un dispositivo que usted controla, es decir. un servidor.