restricciones recuerdo qué olvide hacer eliminar código como codigo borrar activar ios security in-app-purchase itunes-store

recuerdo - Protección contra ataques para compras dentro de la aplicación de iOS



restricciones ios 12 (1)

El sistema de compra de aplicaciones para iOS de Apple ha sido atacado en el pasado por personas que han engañado a las aplicaciones para que les den contenido de forma gratuita. Desde entonces, han mejorado los sistemas involucrados para tratar de limitar este tipo de cosas.

He leído los documentos de referencia de StoreKit disponibles en Apple y tengo una idea general del flujo de trabajo y los controles que deben realizarse, y así sucesivamente. Sin embargo, puede haber problemas de seguridad que no conozco.

¿Alguien puede proporcionar una lista completa de los ataques de robo que pueden intentarse contra los mecanismos de compra en la aplicación, cómo los desarrolladores pueden permitir estos ataques por error y cuáles son las mejores prácticas para prevenirlos?

Estos son los ataques que conozco, pasados ​​y presentes:

App Store falso

Hecho famoso por el programador ruso Alexey Borodin , este ataque solo afecta a las aplicaciones que verifican los recibos de compra directamente con App Store. Al modificar la configuración de DNS del dispositivo e instalar certificados de seguridad falsificados, las solicitudes de verificación se envían a un servidor de App Store falso, que automáticamente devuelve que la compra es válida. Las aplicaciones confiadas aceptarán estas llamadas de verificación y entregarán el contenido al usuario.

Comentario

Después de que se conociera esta vulnerabilidad en julio de 2012, Apple emitió documentación actualizada y consejos para los desarrolladores para garantizar que este tipo de ataque no continuaría ocurriendo. Borodin ha sido citado en varios artículos de la web afirmando que el "juego se acabó" según las API actualizadas de Apple y las pautas de mejores prácticas.

Prevención

Apple tiene un documento completo dedicado a esta laguna here . (EDITAR: El enlace está caído, Wayback si quiere ... aunque el documento cubría iOS 5.1 y anterior). Verifique el recibo con Apple. Sin embargo, si envía el recibo directamente desde la aplicación a la App Store, ellos recomiendan los siguientes cheques:

  • Compruebe que el certificado SSL utilizado para conectarse al servidor de App Store sea un certificado EV.
  • Compruebe que la información devuelta de la validación coincida con la información en el objeto SKPayment.
  • Compruebe que el recibo tiene una firma válida.
  • Compruebe que las nuevas transacciones tengan un ID de transacción único.

Servidor de verificación falso

Si su aplicación envía los recibos de la transacción a su servidor, que luego los reenvía a la App Store, una opción es que el atacante falsifique su servidor de verificación. Por algún método (alterando la tabla DNS, cambiando la URL, etc.) el recibo se envía a una ubicación alternativa y se devuelve una "verificación exitosa". De esta manera, el recibo nunca llega a su servidor y nunca tendrá la oportunidad de verificarlo con la App Store.

Comentario

Aparentemente hay una variedad de aplicaciones en la tienda de Cydia que sirven para ejecutarse en segundo plano, monitorear el tráfico de recibos y redirigirlo para este propósito. Fuente: Hussulinux Blog

Prevención

Si envía contenido de inmediato tan pronto como se verifica un recibo, no hay forma conocida de evitar este tipo de ataque. Sin embargo, tome este escenario: tiene un sistema de cuenta de usuario administrado en su propio servidor. Si el propósito de la Compra In-App es notificar a su servidor que una cuenta de usuario en particular ha comprado un artículo, y la aplicación descarga ese elemento desde su servidor, usted es inmune al ataque. Redirigir el recibo a otro servidor no logrará nada para el atacante, ya que su servidor nunca marcará la cuenta de usuario como propietaria de un elemento, ya que nunca ve el recibo.

Recibos falsos

Un atacante puede falsificar el proceso de compra y luego enviar un recibo falsificado a su servidor de verificación. A diferencia del ataque anterior, la ubicación de salida del recibo no se cambia, pero se reemplaza con un impostor. Este recibo falsificado es, de hecho, un recibo válido de una transacción anterior de la App Store, y la App Store lo verificará como tal. Al simular el proceso de compra y luego enviar un recibo falsificado a su servidor, el contenido nunca se paga.

Comentario

Aparentemente hay una variedad de aplicaciones de Cydia que hacen este tipo de cosas. Puede detectar recibos falsos porque su product_id es totalmente diferente de cualquier cosa que use en su aplicación. Al parecer, la identificación falsificada más famosa es com.zeptolab.ctrbonus.superpower1 . Fuente: Hussulinux Blog .

Prevención

En el enlace donde encontré este ataque, el blogger recomendó que desempaquetara el recibo en su servidor de verificación (base64_decode) y verificara product_id antes de enviar el recibo a la App Store. Sin embargo, en este artículo, Apple recomienda que primero envíe el recibo a la App Store y luego lea la información devuelta para asegurarse de que el recibo sea válido.

(También corríjame si me equivoco, pero la técnica recomendada de Apple también podría usarse para evitar este tipo de ataque incluso si no tiene un servidor de verificación. Si su aplicación envía el recibo directamente a la App Store, podría Examine el contenido de la respuesta JSON para asegurarse de que sea válida. Pero esto va en contra de las mejores prácticas recomendadas por Apple de usar un servidor de verificación externo, por lo que no lo recomendaría.

Para concluir

Estos son los ataques de los que soy consciente, siéntase libre de corregirme si me equivoco en algún punto o de lanzar ataques y correcciones adicionales.

Como nota, hay este sitio web: http://www.in-appstore.com/ que pretende permitir compras dentro de la aplicación de forma gratuita, ya sea en iOS 5 o con un dispositivo iOS 6 con jailbreak, y está activo a partir del 5 de julio. , 2013. Si bien no estoy 100% seguro de cómo lo están haciendo, definitivamente parece implicar redireccionamiento de DNS y certificados de seguridad falsos, lo que implicaría Fake App Store o Fake Verification Server, lo que además implicaría que todavía hay aplicaciones disponibles. Allí que no están asegurados contra estos ataques.

Recursos

EDITAR:

Adicional

Parece que una o dos personas pasaron por aquí y encontraron útil esta publicación, y me alegro.

Se puede obtener más información sobre este tema, ya sea en otras publicaciones, libros o, si así lo desea, en los puntos débiles de Internet. Aquí hay solo un par de sitios web y publicaciones, etc., que quiero investigar, pero aún no he tenido la oportunidad. Agregaré más enlaces más adelante cuando encuentre tidbits interesantes.

http://www.se7ensins.com/forums/threads/tut-how-to-hack-ios-games-and-apps.701845/ http://www.iapphacks.com/

Un par de comentarios inmediatos: no almacene los datos de su jugador en una simple lista a menos que quiera que un adolescente los edite. Las personas no tienen que piratear su sistema IAP si solo pueden darse oro o algo similar editando los archivos en el disco. Quizás al cifrar estos archivos, podría desalentar a cierto segmento de atacantes.

Basado en el enlace se7ensins, parece que un atacante también puede separar su binario y meterse con él para lograr los mismos fines que la edición de un archivo plist, o incluso más, pero esto requerirá un nivel de habilidad ligeramente superior. Quizás establecer una detección de fuga de la cárcel sea suficiente para disuadir a la mayoría de las personas que recurrirían a esto.

Una vez más, esta sección es principalmente especulación, pero puede ayudar a alguien. Realmente, el nivel de protección que tiene depende de cuánto está dispuesto a llegar un desarrollador (por el agujero de la seguridad y el cifrado) para proteger sus resultados.