¿Qué medidas de protección se requieren en la facturación de la aplicación de Android para productos no consumibles?

2

La aplicación es un cliente de Android para un servicio remoto en el que todos los usuarios tienen cuentas y pueden realizar compras de artículos no consumibles. Cada compra está vinculada a la cuenta en la que fueron comprados. El esquema de compra actual es el siguiente:

  1. El cliente inicia la compra con el servicio de facturación en la aplicación Google Play. La solicitud de compra contiene la carga útil que identifica de forma única a la cuenta.
  2. Cuando la compra se completa con éxito, el cliente recupera los datos de compra que contienen la carga útil y el token de compra. También tiene una firma para los datos recibidos que actualmente no están verificados.
  3. El cliente envía el token de compra al servidor. En este punto tiene que ser autenticado.
  4. El servidor recibe el token de compra. El servidor se autentica con el servicio Google Play usando su clave de cuenta de servicio y recibe los datos de compra para el token dado. Los datos contienen la carga útil original y la información sobre la compra.
  5. El servidor valida los datos de compra: se verifica que la carga útil coincida con la identificación de usuario actualmente registrada, la compra aún no se ha consumido y se ha pagado con éxito.
  6. Si la verificación es exitosa, se marca que el cliente ha comprado el producto en el servidor y el cliente recibe una confirmación; de lo contrario, el cliente recibe un rechazo.

¿Qué podría salir mal con este esquema? Por ejemplo, me preocupa que la firma no se use en ninguna parte. Sin embargo, no veo qué uso hay en él si el servidor recibe los datos directamente de Google Play. En el peor de los casos, puede recibir un token incorrecto, pero la carga útil contiene la identificación del usuario, por lo que la compra se rechazará si se ha realizado para otra cuenta. Enviar el mismo token dos veces también es inútil ya que el producto no es consumible: se compró o no se compró. Pero tal vez me esté perdiendo algo aquí o hay algún otro defecto que no veo.

    
pregunta Malcolm 02.08.2016 - 16:16
fuente

2 respuestas

1

¿No entiendo cuál es realmente la pregunta?

Sospecho que su pregunta es más, ¿para qué se usa la firma, si nunca se verifica? Y puedo decir aquí para qué se usa la firma: la firma se usa cuando no tiene un sistema de cuentas subyacente y tampoco está usando el sistema de cuentas de Google.

En ese caso, recibe los datos de compra firmados del servidor de Google en la aplicación. Ahora surge el problema de que el usuario podría manipularlo, decir que podría hacerlo para decir que compró algo que no compró.

Tampoco tiene una ID de usuario para validar, por lo que si solo usó el token de compra, el usuario podría compartir tokens entre sí.

Esto es lo que la firma entra en juego. Cuando recibe los datos de la aplicación / cliente / usuario, puede verificar que no se haya controlado antes de permitir el acceso a los servicios de pago. Además, aquí puede proporcionar un nonce aleatorio con su solicitud, que se da en la respuesta. Dado que el usuario no puede obtener datos de compra para ninguna otra compra que no sea su propia compra, esto evita efectivamente el intercambio de contenido premium.

Agregar la validación de los datos de compra en la parte superior de tu esquema lo haría aún más seguro, pero en este caso, no es necesario ya que estás validando el token contra UserID.

    
respondido por el sebastian nielsen 07.08.2016 - 03:33
fuente
1

Tienes razón, tampoco veo ningún problema en este esquema. Si Google comienza a mentirle a su servidor sobre compras ficticias, dudo que una firma ayude, ya que en ese momento necesitaría cambiar por completo a los proveedores de pago.

    
respondido por el André Borie 06.08.2016 - 04:07
fuente

Lea otras preguntas en las etiquetas