Aplicación segura para iPhone communication comunicación del servidor

¿Cuál sería el mejor enfoque para lograr una comunicación privada entre mi aplicación iOS y su componente de servidor? ¿Es suficiente tener una sola "clave secreta" inmutable en la fuente de la aplicación, o necesito configurar de forma dinámica generaciones de tales claves "apretón de manos"?

El servidor por sí solo no tiene acceso a ningún dato confidencial, por lo que incluso si el usuario alcanza algunos puntos finales privados, no los llevará a ninguna parte, pero solo quiero que estén ocultos para el público. Básicamente, quiero ignorar todas las solicitudes que lleguen a rutas particulares, a menos que provengan de mi aplicación iOS.

El componente del servidor se ejecuta en RoR, si eso es importante.

No puede rechazar efectivamente las conexiones a menos que proporcione a cada cliente una clave privada que puede revocar individualmente. Pero esto es probablemente exagerado. No necesita una solución a prueba de balas si la mayoría de las personas no se molestan en disparar una bala.

Es una pregunta de seguridad, así que describamos un modelo de amenaza y estrategias de mitigación.

Supongamos que tiene una URL que golpea y puede incurrir en un costo notable para usted (por ejemplo, costo de procesamiento), y desea protegerlo tanto de un ataque DoS simple como de aplicaciones copycat.

Use SSL para ocultar la conexión y evitar que se analice fácilmente. Use un número de puerto no obvio, una secuencia de redireccionamiento, un intercambio de cookies para complicar la conexión un poco antes de hacer la parte costosa de la solicitud. Use un código secreto integrado en su aplicación para que el servidor sepa que tiene que aceptar la conexión.

Ahora alguien no puede aprender la URL costosa de golpear simplemente ejecutando un rastreador de paquetes o mirando cadenas similares a URL en su código. Un atacante potencial tiene que descompilar su aplicación.

Realmente no puede proteger su código de ser descompilado y / o ejecutado bajo un depurador. El atacante finalmente aprende la clave secreta y la secuencia de conexión.

Observa que comienza a recibir solicitudes de rouge en su costosa URL: ya sea en forma de ataque o en forma de una aplicación copycat que tiene que acceder a su servicio para ejecutarse, o tal vez se publique un código de explotación. Sin embargo, no puede distinguir una solicitud fraudulenta de una solicitud legítima.

Cree una actualización menor gratuita para su aplicación, con una clave secreta diferente. Debe golpear una URL costosa diferente que sirve los mismos datos que la URL costosa comprometida. Durante algún tiempo, haga que ambas URL sean accesibles.

Vea cómo su base de usuarios cambia a la versión actualizada. Acelere la costosa URL comprometida y eventualmente la 404. Acaba de mitigar una violación de seguridad, con suerte sin perder demasiado. Volver al punto de partida.

Descargo de responsabilidad: no soy un experto en seguridad.

Tienes un problema clásico que realmente no se puede resolver.

Para garantizar una privacidad simple (es decir, asegurarse de que sus datos no puedan ser indagados o alterados en tránsito) puede hacer todo a través de SSL y otorgar a su servidor un certificado emitido adecuadamente por una CA que el iPhone reconoce.

Sin embargo, para la autorización, no hay una buena solución que garantice al 100% que nadie más que su aplicación pueda acceder a la API. Tu solución propuesta sería trabajar, excepto:

• cualquier persona que haya descargado su aplicación necesariamente tiene en su poder la clave privada
• si de alguna manera logran desempaquetar su aplicación y descompilarla, tendrán la clave privada en texto plano
• Una vez que tienen la clave privada en texto plano, pueden usarla para firmar sus propias solicitudes maliciosas.

No hay forma de evitar esto. No quiere decir que no pueda adoptar ese enfoque, pero comprenda que no es infalible. Es este mismo problema el que hace que DRM sea completamente ineficaz .

Esto es lo que TLS y SSL . Cualquiera de los dos puede crear una conexión segura sin la necesidad de una clave secreta fija. Lea la sección Descripción en la página vinculada para saber cómo lo hacen.

Una manera efectiva de obtener el beneficio de TLS / SSL sin tener que hacer mucho (ningún) trabajo es hacer que su servidor implemente un servicio web al que accede el cliente utilizando el protocolo HTTPS. HTTPS es solo HTTP a través de una conexión segura, y el sistema de carga de URL en iOS lo implementa por usted.