Aplicación para iPhone con un servidor backend: ¿cómo garantizar que todo el acceso sea solo desde la aplicación iPhone?

Question

No me importa mucho piratear, etcétera, pero quiero asegurarme de que el backend (basado en Rails) no esté abierto a servicios automáticos que lo puedan hacer en DOS, etc. Por lo tanto, me gustaría simplemente asegurarme de que todo acceso a el backend (que serán algunas consultas REST para los datos GET y PUT) se realizará a través de una aplicación de iPhone válida, y no de una secuencia de comandos ejecutándose en una máquina.

Quiero evitar el uso de cuentas para que la experiencia del usuario sea perfecta.

Mi primera intención es unir el UDID y un secreto, y proporcionar ese (y el UDID) a través de una conexión HTTPS al servidor. Esto permitirá que se cree una sesión autenticada o devuelve un error.

Si se escucha a escondidas, un atacante podría tomar el hash y volver a reproducirlo, dejando este esquema abierto para reproducir los ataques. Sin embargo, ¿no debería la conexión HTTPS protegerme contra escuchas ilegales?

Gracias!

Answer 1

Como dice bpapa, puede ser falso, pero, como dices, no te preocupa tanto como a nadie que venga y solo envía miles de solicitudes a tu servidor en una fila, y tu servidor tiene para procesar cada uno

Su idea del hash es un buen comienzo. A partir de ahí, también puede agregar la marca de tiempo actual al valor prehechado y también enviarlo. Si la marca de tiempo dada es más de 1 día diferente de la hora actual del servidor, no permita el acceso. Esto detiene los ataques de repetición por más de un día más tarde de todos modos.

Otra opción sería usar un nonce. Cualquiera puede solicitar un nonce de su servidor, pero luego el dispositivo tiene que agregar eso a los datos pre hash antes de enviar el hash al servidor. Los nonces generados tendrían que almacenarse o simplemente podría ser la marca de tiempo actual del servidor. Luego, el dispositivo debe agregar la marca de tiempo del servidor en lugar de su propia marca de tiempo a los datos previos al hash, lo que permite un período mucho más corto que un día completo para que se produzca un ataque de repetición.

Answer 2

No hay forma de asegurarlo, ya que se puede falsificar.

Si realmente quieres seguir esta ruta (sinceramente, a menos que estés haciendo algo realmente súper crítico aquí probablemente estés perdiendo el tiempo), podrías pasar el token de dispositivo de iPhone. O tal vez hash y luego pasarlo. Por supuesto, no tienes manera de validarlo en el lado del servidor ni nada por el estilo, pero si un malo quiere derrotarte, aquí está la barrera # 1 con la que tendrá que lidiar primero.

Answer 3

Use SSL con el certificado del cliente. Tenga una clave privada en su cliente y emita un certificado para ello, y su servidor web puede requerir que este cliente esté presente para que las sesiones continúen.

No puedo dar detalles del código para Rails, pero la arquitectura es lo más seguro que puede hacer, aunque puede ser un poco exagerado. SSL con certificados es una solución estándar de la industria y existen bibliotecas tanto para el extremo del iPhone/cliente como del servidor, por lo que no tiene que inventar nada ni implementar mucho, solo hacer que funcionen bien juntas.

También podría considerar HMAC, como HMAC-SHA1, que es básicamente una estandarización de las cosas hash que otras personas aquí hablan. Si agregas nonces a él, también estarás a salvo contra el ataque de repetición. Para tener una idea acerca de cómo implementar HMAC-SHA1 con nonces, podría ver el protocolo OAuth (no el flujo completo, sino cómo unen el nonce y otros parámetros en una solicitud autenticada).