¿Puede un atacante hacer compras dentro de la aplicación de mis productos en su aplicación?

4

Mi aplicación de iOS necesita almacenar un secreto previamente compartido. No se puede incrustar dentro del propio paquete de aplicaciones porque podría extraerse mediante el análisis estático del paquete.

El sistema In-App-Purchase de Apple permite que una aplicación realice una solicitud a Apple. iOS debe verificar la autenticidad de la aplicación (ya que todas las aplicaciones están firmadas). Me doy cuenta de que puedo usar este sistema para verificar que la aplicación es mía (y no un impostor que intenta obtener el secreto).

Mi aplicación haría una solicitud de IAP a Apple, luego Apple genera un recibo firmado criptográficamente y se lo devuelve a mi aplicación, quien luego pasa el recibo a mi servidor que verifica la firma de Apple y emite un nuevo secreto por instancia de aplicación y lo devuelve al cliente (para almacenamiento en el enclave seguro de iPhone) donde ninguna otra aplicación puede leerlo.

Este sistema se rompería si un atacante pudiera enviar sus propios recibos a mi servicio. Entiendo que el recibo contiene el nombre del paquete / paquete de aplicaciones que Apple afirma que es correcto, pero no sé cómo protegería contra un atacante que realiza un tipo de ataque de repetición en el que obtendría mi aplicación para hacer el IAP, por lo que el recibo es válido, pero capture el recibo, pause el proceso de mi aplicación, luego envíe la receta de su aplicación a mi servicio (obteniendo así el secreto).

¿Cuál es una buena solución para este problema, y podría un teléfono con jailbreak permitir que otra aplicación se enmascare como mi aplicación de Apple para IAP?

    
pregunta The D 07.04.2016 - 10:31
fuente

2 respuestas

2

Su escenario en el que un atacante intercambia un recibo válido por datos secretos se puede mitigar si, en lugar de que el servidor envíe el secreto en respuesta a un recibo, entrega el secreto a su aplicación a través de otros medios. Los servicios de notificaciones push de Apple son una buena solución, ya que vinculan su servidor con sus propias aplicaciones (ninguna otra aplicación puede recibir sus notificaciones y su servidor no puede enviar notificaciones a las aplicaciones de otros desarrolladores, incluso si lo desea, porque el cliente lo certifica el uso de hablar con Apple solo le permite enviar mensajes dirigidos a sus propias aplicaciones).

Cuando solicita los datos secretos del servidor, envía el recibo y su token de dispositivo único que le permite enviar notificaciones de empuje a él. El servidor luego envía los datos secretos como una notificación de inserción. Si el tamaño es un problema, puede enviar una clave secreta que se ajuste a la carga útil de la notificación, y la aplicación descargará los datos secretos reales presentando esa clave en una solicitud posterior. Una aplicación impostora no podría recibir la notificación de inserción porque incluso si envía su propio token, Apple no permitirá que su servidor envíe una notificación a esa aplicación ya que es de un desarrollador diferente.

Finalmente, una pregunta viene a la mente, ¿por qué haces esto? Si los datos secretos contienen información sobre otros usuarios, entonces este es su principal problema. En lugar de tratar de proteger esos datos secretos (que no puede obtener de alguien que tiene acceso físico al dispositivo), solo asegúrese de que los datos no contengan nada sensible sobre otras personas y deje que el usuario haga lo que quiera con < em> sus datos. Si es por DRM, tenga en cuenta que muchas personas lo han intentado y han fallado , y no importa lo inteligente que sea, no puede hacer lo imposible. ¿Por qué no centrar sus esfuerzos en ofrecer una experiencia increíble para alentar a las personas a pagar en lugar de copiar su contenido?

    
respondido por el André Borie 06.08.2016 - 04:00
fuente
0

Cualquier sistema de este tipo que valga la pena (sic) tendrá un MAC basado en el tiempo (o al menos una opción para agregar uno) por exactamente este motivo.

No puedo comentar específicamente sobre el servicio de Apple, pero sé que es algo que, por ejemplo, Azure ofrece para el acceso basado en token a su sistema de almacenamiento en la nube ... Incluso escribí un mecanismo similar para proteger los comandos de transmisión RTSP para pre -el audio de hace unos quince años :)

    
respondido por el Nathan 07.04.2016 - 23:35
fuente

Lea otras preguntas en las etiquetas