Estoy usando la versión 3 de la API de facturación integrada en la aplicación. Tengo un solo artículo administrado, no consumible. Todavía no he lanzado esta función en mi aplicación, por lo que quiero decidir sobre el contenido de la carga útil de compra antes de que haya compras.
De "Prácticas recomendadas de seguridad" :
Establecer la cadena de carga útil del desarrollador al realizar solicitudes de compra
Con la API de facturación integrada en la aplicación versión 3, puede incluir un token de cadena de 'carga útil del desarrollador' al enviar su solicitud de compra a Google Play. Por lo general, esto se usa para pasar un token de cadena que identifica de manera única esta solicitud de compra. Si especifica un valor de cadena, Google Play devuelve esta cadena junto con la respuesta de compra. Posteriormente, cuando realiza consultas sobre esta compra, Google Play devuelve esta cadena junto con los detalles de la compra.
Debes pasar un token de cadena que ayude a tu aplicación a identificar al usuario que realizó la compra, para que luego puedas verificar que se trata de una compra legítima de ese usuario. Para los artículos consumibles, puede usar una cadena generada aleatoriamente, pero para los artículos no consumibles debe usar una cadena que identifique de forma única al usuario.
Cuando reciba la respuesta de Google Play, asegúrese de verificar que la cadena de carga útil del desarrollador coincida con el token que envió anteriormente con la solicitud de compra. Como medida de seguridad adicional, debe realizar la verificación en su propio servidor seguro.
Con razón o sin ella, he decidido no tomar la "precaución de seguridad adicional" de configurar un servidor para realizar la verificación de compra. Y no guardo mi propio registro de la compra, siempre llamo a la API de facturación. Entonces, ¿realmente hay alguna razón para que yo haga esta verificación de carga útil? La API de verificación en sí misma ciertamente verifica la identidad de un usuario antes de informar sobre un artículo como comprado, y si un atacante ha comprometido un dispositivo (ya sea la aplicación o la API de Google Play), no veo ningún beneficio de hacer una verificación adicional en la identificación del usuario en el dispositivo donde se puede eludir fácilmente. ¿O hay alguna razón para hacer esto en la que no estoy pensando?
fuente
Si su aplicación proporciona su propio inicio de sesión e identidad de usuario, que es diferente de las cuentas de Google a las que está conectado el teléfono, entonces necesitará usar la carga útil del desarrollador para adjuntar la compra a una de sus cuentas que realizó la compra. De lo contrario, alguien podría cambiar de cuenta en su aplicación y beneficiarse de las cosas compradas.
p.ej
Supongamos que nuestra aplicación tiene inicio de sesión para usuarioA y usuarioB. Y la cuenta de Google de Android del teléfono es X.
Para evitar dicho uso indebido, vincularemos una compra a una cuenta. En el ejemplo anterior, estableceremos la carga útil del desarrollador como "usuarioA" cuando el usuarioA esté realizando la compra. Entonces, cuando el usuario B inicia sesión, la carga útil no coincidirá con el usuario que inició sesión (usuario B), e ignoraremos la compra. Por lo tanto, el usuario B no puede obtener beneficios de una compra realizada por el usuario A.
fuente
developerPaylodTambién hay otro enfoque para el manejo de la carga útil del desarrollador. Como dijo Nikolay Elenkov, es demasiada sobrecarga requerir una identificación de usuario y establecer permisos adicionales para el perfil de usuario en su aplicación, por lo que este no es un buen enfoque. Entonces, veamos lo que dice Google en la última versión de la aplicación de muestra TrivialDrive en las muestras de facturación en la aplicación v3:
Por lo tanto, la cadena aleatoria no es una buena idea si va a verificar el artículo comprado en otro dispositivo, pero aún así no dicen que no sea una buena idea para verificar la respuesta de compra. Yo diría: use la carga útil del desarrollador solo para verificar la compra enviando una cadena única aleatoria, guárdela en preferencias / base de datos y en la respuesta de compra verifique esta carga útil del desarrollador. En cuanto a consultar el inventario (compras en la aplicación) al inicio de la actividad, no se moleste en verificar la carga útil del desarrollador, ya que eso podría suceder en otro dispositivo donde no tiene almacenada esa cadena única aleatoria. Así lo veo yo.
fuente
Depende de cómo verifique el
developerPayload. Hay dos escenarios: verificación remota (usando el servidor) y local (en el dispositivo).Servidor
Si está utilizando un servidor para la
developerPayloadverificación, puede ser una cadena arbitraria que se puede calcular fácilmente tanto en el dispositivo como en el servidor. Debería poder identificar al usuario que ha realizado la solicitud. Suponiendo que cada usuario tiene el correspondienteaccountId,developerPayloadse puede calcular como combinación conpurchaseId(nombre de SKU) de esta manera:MD5(purchaseId + accountId)Dispositivo
developerPayloadno debería ser el correo electrónico del usuario . Un buen ejemplo de por qué no debería utilizar el correo electrónico como carga útil es el servicio Google for Work. Los usuarios pueden cambiar su correo electrónico asociado con la cuenta. Lo único constante esaccountId. En la mayoría de los casos, el correo electrónico estará bien (por ejemplo, las direcciones de Gmail son inmutables en este momento), pero recuerde diseñar para el futuro.Varios usuarios pueden usar el mismo dispositivo, por lo que debe poder distinguir quién es el propietario del artículo. Para la verificación del dispositivo
developerPayloades una cadena que identifica de forma única al usuario, por ejemplo:MD5(purchaseId + accountId)Conclusión
Generalmente,
developerPayloaden ambos casos puede ser solo elaccountId. Para mí, parece seguridad a través de la oscuridad . El MD5 (u otro algoritmo de hash)purchaseIdes solo una forma de hacer que la carga útil sea más aleatoria sin mostrar explícitamente que estamos usando la identificación de la cuenta. El atacante tendría que descompilar la aplicación para comprobar cómo se calcula. Si la aplicación está ofuscada, aún mejor para ti.La carga útil no proporciona ninguna seguridad . Se puede falsificar fácilmente con el enfoque de "dispositivo" y sin ningún esfuerzo en la verificación del "servidor". Recuerde implementar la verificación de firmas con su clave pública disponible en la consola de la cuenta de editor de Google.
* Una publicación de blog de lectura obligatoria sobre el uso de la identificación de la cuenta en lugar del correo electrónico.
fuente
En el video de Google IO sobre IAB v3 dado por el autor de la muestra trivial de manejo, esto se abordó brevemente hacia el final del video. Es para evitar ataques de reproducción, por ejemplo, el atacante olfatea el tráfico, roba el paquete que contiene una compra exitosa y luego intenta reproducir el paquete en su propio dispositivo. Si su aplicación no verifica la identidad del comprador a través de la carga útil de desarrollo (idealmente en su servidor) antes de lanzar el contenido premium (también idealmente desde su servidor), el atacante tendrá éxito. La verificación de la firma no puede detectar esto porque el paquete está intacto.
En mi opinión, esta protección parece ideal para aplicaciones con conectividad de cuenta en línea como Choque de clanes (la carga útil viene naturalmente ya que tienes que identificar a los usuarios de todos modos), especialmente cuando la piratería compromete el juego multijugador con efectos de gran alcance que no sean un simple caso localizado de piratería. . Por el contrario, si los hacks del lado del cliente en la apk ya pueden desbloquear el contenido premium, esta protección no es muy útil.
(Si el atacante intenta falsificar la carga útil, la verificación de la firma debería fallar).
fuente
Actualización de finales de 2018: la biblioteca oficial de facturación de Google Play no expone intencionalmente el
developerPayload. Desde aqui :fuente
Luché con este. Dado que una cuenta de Google Play solo puede poseer uno de los elementos "administrados", pero podría tener varios dispositivos (tengo tres), el comentario anterior de alguien de que vendes un "por dispositivo" no funcionará ... poder ponerlo en su primer dispositivo, y nunca en otros ... Si compra una actualización premium, debería funcionar en todos sus teléfonos / tabletas.
Detesto la idea de obtener la dirección de correo electrónico del usuario, pero realmente no encontré ningún otro método confiable. Así que agarro la primera cuenta que coincide con "google.com" en la lista de cuentas (sí, un permiso para agregar a su manifiesto), y luego inmediatamente la hash para que ya no se pueda usar como una dirección de correo electrónico, pero proporciona un "lo suficientemente único "token. Eso es lo que envío como Carga útil del desarrollador. Dado que la mayoría de las personas activan su dispositivo con su ID de Google Play, es muy probable que los tres dispositivos obtengan el mismo token (utilizando el mismo algoritmo hash en cada dispositivo).
Incluso funciona en KitKat con múltiples "usuarios". (Mi identificación de desarrollador está en un usuario, mi identificación de prueba en otro y cada usuario en su propia caja de arena).
Lo he probado en seis dispositivos con un total de 3 usuarios y cada uno de los dispositivos de los usuarios ha devuelto el mismo hash, y los diferentes usuarios tienen distintos hashes, cumpliendo las pautas.
En ningún momento estoy almacenando la dirección de correo electrónico del usuario, se pasa directamente desde el código para obtener los nombres de las cuentas a la función hash y solo el hash se guarda en el montón.
Probablemente todavía exista una solución mejor que respete aún más la privacidad de los usuarios, pero hasta ahora no la he encontrado. Voy a poner una descripción muy clara de cómo uso la dirección de correo electrónico de los usuarios en mi política de privacidad una vez que se publique la aplicación.
fuente
Esto a menudo responde a una definición de producto (su aplicación). Por ejemplo para el caso de las suscripciones. ¿Podrá el mismo usuario utilizar la suscripción en todos los dispositivos que tenga? Si la respuesta es sí. No comprobamos la carga útil.
Para consumibles. Suponga que una compra en su aplicación le da 10 monedas virtuales. ¿El usuario podrá usar estas monedas en diferentes dispositivos? ¿4 en un dispositivo y 6 en otro? Si queremos trabajar solo en el dispositivo que realizó la compra tenemos que verificar la carga útil, por ejemplo, con una cadena autogenerada y almacenada localmente.
Basándonos en estas preguntas, tenemos que decidir cómo implementar la verificación de carga útil.
Saludos
Santiago
fuente