verificacion sesion servidor restricciones problema olvide ocurrio iniciar imposible error eliminar desactivar conectar con como codigo apple ios security authentication passwords nsurlsession

ios - sesion - olvide codigo de restricciones iphone



La seguridad se refiere al envío de nombre de usuario y contraseña al servidor a través de https desde la aplicación iOS (2)

Estás imaginando a un hacker invirtiendo tu binario ofuscado para tratar de obtener el nombre de usuario y la contraseña. Esa es la manera más difícil de hacerlo. La manera más fácil es inspeccionar el tráfico de la red.

Sí, el propietario del dispositivo puede pasar fácilmente por alto el TLS incluso sin tener que jailbreaking. TLS protege contra atacantes externos, pero no protege contra algo que quiera inspeccionar su propio tráfico de red. Esto es muy fácil de hacer, ver por ejemplo las instrucciones en mi blog donde vencí a un juego de iOS muy popular .

Si desea detener este ataque más fácil, puede intentar implementar la fijación de certificados . Eso todavía se puede romper fácilmente en un dispositivo con jailbreak, pero disuade a muchos hackers ocasionales que no querrán hacer jailbreak en su dispositivo.

Al final del día, tienes razón en que un hacker determinado va a ganar contra este tipo de diseño.

He configurado la verificación de recibo de compra de la aplicación de acuerdo con las recomendaciones de Apple enviando el recibo a mi servidor, que a su vez lo envía a los servidores de Apple para su verificación. Todo el procesamiento de recibos se maneja desde el lado del servidor y funciona perfectamente. Mi servidor devuelve un código muy oscuro a mi aplicación para confirmar si la compra es válida o no. Utilizo un método de ofuscación bastante robusto en el lado de la aplicación para disfrazar lo que está sucediendo con ese código de retorno para hacerlo lo más difícil posible sobre piratas informáticos para vencerlo.

El problema es que tengo mis archivos php almacenados en una carpeta protegida con contraseña en mi servidor web, y me preocupa cómo se puede considerar seguro cuando la aplicación tiene el nombre de usuario y la contraseña para que ese directorio incrustado en él envíe el recibo al archivo php para comenzar.

Mi aplicación solo usa el servidor para autenticación de recibo de compras en aplicaciones. Todas las otras funcionalidades se encuentran en la propia aplicación, por lo que no obligo a cada usuario a tener una cuenta con un nombre de usuario y contraseña únicos.

Estoy usando URLSession para comunicarme con el servidor a través de una conexión https TLS 1.2 para que esa parte sea segura, pero no puedo pensar en una forma de evitar que un hacker determinado extraiga el nombre de usuario y la contraseña de la aplicación en su dispositivo, y tener acceso a la carpeta de mi servidor directamente. Alguien con esa capacidad podría fácilmente modificar el archivo php para devolver siempre un código que indique una compra válida.

Ofusco el nombre de usuario y la contraseña dentro de la aplicación hasta el punto que creo que la mayoría de la gente probablemente se daría por vencida al tratar de resolverlo, pero sé que solo lo he hecho más difícil de extraer, no casi imposible.

Tiene alguna idea sobre esto? Casi todo lo que encontré en línea con respecto a esto se ha referido a no transmitir un nombre de usuario y contraseña a través de http, no el problema más grande de un dispositivo con jailbreak.


Así que creo que he encontrado una solución bastante segura para este desastre. Muchas gracias a las personas que se tomaron el tiempo para comentar sobre esto, ya que sus aportaciones fueron ciertamente útiles.

En primer lugar, aunque tengo bastante experiencia con el desarrollo de iOS de Obj-C / Swift, las cosas del lado del servidor son bastante nuevas para mí, pero estoy aprendiendo bastante rápido. Lo que puede parecer un gran momento de eureka para mí, parecerá bastante rutinario para un gran experto de REST / Linux / PHP, así que tengan paciencia conmigo.

Para resumir el desafío: quería enviar una representación json de un recibo de compra en la aplicación desde mi aplicación a un archivo .php en mi servidor para que pueda enviarlo a Apple para su verificación. Para proteger ese archivo .php, coloqué un archivo .htaccess en su carpeta para solicitar un nombre de usuario y una contraseña para acceder a él.

NSURLSession trató esto muy bien, pero me pidió que pusiera el nombre de usuario y la contraseña en la aplicación ... no es bueno. Eso fue lo que activó la conversación de ofuscación y me hizo darme cuenta de que no había forma de mantener la contraseña segura al codificarla en la aplicación.

Luego me di cuenta de que podía estacionar archivos fuera de mi carpeta public_html (mi momento eureka), y eso es lo que hice. Así que dentro de la carpeta public_html, que también tiene un archivo index.html, ahora tengo un archivo .php muy simple que no hace más que llamar a una función en otro archivo .php que hace todo el trabajo hablando con los servidores de Apple y analizando la respuesta. Cuando ha finalizado el análisis, devuelve un código muy oscuro (no los códigos bien publicitados que Apple devuelve) al archivo .php simple que a su vez lo devuelve a mi aplicación.
En función de ese código, la aplicación decidirá si otorga o no acceso a los productos comprados.

Usando permisos del lado del servidor he restringido el archivo .php simple en el directorio public_html del acceso de lectura o escritura del "mundo", dejándolo como ejecutable solamente. Entonces, si un pirata informático puede obtener rápidamente el nombre de ese archivo si piratea la aplicación, no debería servirles de nada. Ya no necesito un nombre de usuario o contraseña en la aplicación, y el archivo .php "principal" que hace que todo el trabajo viva en una carpeta que está fuera de la carpeta public_html, tiene sus permisos establecidos para restringir la lectura / escritura / ejecución del "mundo", y aunque creo que es excesivo, puse un archivo .htaccess allí y lo niego todo.

Creo que tengo una solución "bastante segura" aquí que debería hacer que sea bastante difícil para un hacker casual robar una compra en la aplicación, pero como siempre estoy abierto a sugerencias en caso de que me haya perdido algo.