2009-05-11 14 views
9

Estoy escribiendo un servicio web muy simple para mi aplicación de iPhone. Digamos que esta es una página http que devuelve un número aleatorio al http://mysite/getRand. ¿Cómo me aseguro de que solo se pueda acceder a esta página desde mi aplicación de iPhone y no desde otros clientes? He pensado en hacer algún mecanismo de contraseña simple, pero eso puede ser olfateado fácilmente al capturar lo que envía mi aplicación.¿Cómo asegurar el acceso a mi servicio web solo desde mi código?

La razón de esto es para reducir la carga de mi servidor al permitir únicamente solicitudes legítimas.

Respuesta

0

No estoy seguro de qué tecnología web está utilizando, pero si usa Ruby on Rails, usa un token de autenticación secreto en todos sus controladores para asegurarse de que el código malicioso no acceda a métodos destructivos (a través de PUSH , POST o ELIMINAR). Debería enviar ese token de autenticación al servidor en su cuerpo de solicitud para permitir su ejecución. Eso debería lograr lo que creo que estás buscando.

Si no está utilizando Ruby on Rails, ese método de autenticación de código puede ser una buena investigación e implementación en cualquier tecnología que esté utilizando.

Eche un vistazo a Rails Security Guide, específicamente la sección 3.1 (Contramedidas de CSRF).

0

Puede hacer algo como cifrar la hora actual y la dirección IP desde el iPhone, y luego descifrarlo en el servidor. La desventaja es que necesitas que la aplicación de iPhone conozca la clave "secreta" para que solo pueda generar tokens de acceso válidos ... y una vez que la clave está en libertad, solo será cuestión de tiempo antes de que sea pirateada si tu la aplicación realmente vale la pena el esfuerzo.

Puede encriptar la respuesta usando alguna porción aleatoria de la aplicación que se supone que debe usarla, especificando la ubicación del binario en un bit de la respuesta sin encriptar. Entonces, al menos, solo los clientes con acceso a su binario podrían descifrarlo ... pero una vez más, eso no es 100% seguro.

En última instancia, debe preguntarse cuánto esfuerzo desea dedicar a la seguridad del servicio frente a la cantidad de esfuerzo que cree que los hackers utilizarán para abusar de él.

0

No soy desarrollador de Cocoa Touch, pero creo que HTTP Authentication over SSL sería fácil de implementar y probablemente sea exactamente lo que está buscando.

Todo lo que necesita hacer es configurar Autenticación HTTP en el lado del servidor (no ha mencionado lo que está utilizando en el lado del servidor) y crear un certificado SSL autofirmado en su servidor web. Hecho. :)

Cuéntanos más acerca de tu configuración y podremos ayudarte aún más.

+0

¿Cómo evita que otra aplicación que usa HTTPS acceda al servicio? Sí, el hacker tendría que averiguar los detalles de autenticación que se utilizan, pero si asumimos que es un hacker ingenioso, no creo que esto los detenga. –

+0

Como usted mismo se preguntó: La pregunta es cuánto esfuerzo quiere poner para asegurar el servicio. Claro, un hacker ingenioso podría usar un ataque MITM para recuperar el nombre de usuario/contraseña del tráfico cifrado con SSL, pero creo que este es un buen equilibrio entre beneficio y costo. – Javier

11

Realmente no se puede hacer esto. Su aplicación puede ser desmontada y cualquier secreto que esté en el binario puede ser replicado en una aplicación maliciosa.

Otro ataque que debe tener en cuenta es la configuración de las personas que los hosts archivan en una ubicación que controlan y luego instalar un certificado raíz que les permita proporcionar una firma para ese dominio. Su aplicación publicaría el secreto, y solo podrían leer el secreto. Podrían extraer la contraseña de cualquier sistema de encriptación complicado dentro del binario de esta manera.

La mayoría de las ideas en este hilo son vulnerables a este ataque.

Dicho esto, la probabilidad de que alguien se preocupe lo suficiente como para desarmar su aplicación es probablemente bastante remota.

Lo mantendría simple. Tener una contraseña codificada en su aplicación. Para evitar que alguien solo mire los recursos y pruebe cada cadena, conviértalo en el XOR de dos cadenas o en el resultado de un descifrado AES de una cadena fija determinada.

Obviamente, debe realizar la solicitud a través de SSL; de lo contrario, un atacante puede husmear el tráfico.

Sí, un atacante determinado eludirá el esquema, pero como cualquier esquema de DRM, ese siempre ha sido el caso. El truco es hacer demasiado esfuerzo para valer la pena.

+1

de acuerdo. Al igual que toda seguridad, el truco es hacer que el costo beneficio de acceder al servicio sea pobre. –

1

Usaría también el protocolo https con las teclas del lado del cliente. Puede usar una clave de cliente para todos o incluso puede generar una clave diferente para cada cliente y "registrarla" en su servidor.

Supongo que es mucho trabajo para proyectos pequeños, pero parece que es lo correcto si necesita autenticación.

Debe verificar que el propietario del teléfono móvil no vea fácilmente las claves. Y recuerda que alguien podrá hackearlo en cualquier caso.

1

Supongo que no desea utilizar SSL? Si lo hace, puede abrir la sesión HTTPS y luego pasar una clave secreta en la solicitud.

Si no quieren SSL sus opciones son limitadas: para tener la seguridad de pseudo Sugiero ambos métodos de autenticación y autorización, y una tercera para reducir el tráfico global:

Autenticación: Generador de aplicación de cliente que crea claves secretas de combinando con un archivo de clave. El archivo de claves se puede actualizar de vez en cuando para mayor seguridad: digamos que actualiza el archivo de claves una vez a la semana. Volver a cap: Generator combina el secreto de la aplicación con el archivo de la clave de la aplicación para generar una tercera clave para la transmisión utilizada en la autenticación. El servidor podría entonces autenticarse.

Autorización: por supuesto, también desea bloquear las aplicaciones deshonestas. Aquí sería mejor tener un mecanismo de autorización con el sitio. No reemplace los archivos de claves a menos que el cliente inicie sesión. Haga un seguimiento de los archivos de claves a los usuarios. etc. Reducción de tráfico: Si está recibiendo una cantidad obscena de tráfico o si sospecha que alguien intenta conectar su servidor con DOS, también puede sincronizar el servidor y los clientes para solicitar/responder en una URL generada procesalmente que puede cambiar a menudo Es un desperdicio abrir/cerrar tantas sesiones HTTPS si alguien solo lo inunda con solicitudes.

2

Para seguir la idea de Simon, podría fácilmente tener una cadena clave en su aplicación, luego enviar la ID del dispositivo, y luego el DeviceID XOR'ed (o algún otro algoritmo simple para el cifrado de cadenas) con su cadena de teclas .

Dado que conoce el valor de clave que debe usar, es trivial "descifrar" esta cadena en el lado del servidor y verificar que los valores coincidan.

De esta manera, la contraseña es diferente para cada dispositivo del usuario, y la cadena "clave" nunca se envía a través de los cables de los grandes internets sin lavar. :-)

Sí, esto de ninguna manera sería imposible de entender, pero como otros han dicho, la idea no es hacerlo imposible. La idea es hacerlo más problemático de lo que vale.

0

Como han afirmado algunas de las respuestas, cerrar su servicio web a todos los demás será una gran molestia.Lo mejor que puede esperar es facilitarles a los hackers el uso de otro servicio web, que usar el suyo ...

Otra sugerencia para hacer esto, es generar números aleatorios a partir de un random seed en el servidor y el cliente. El servidor necesitaría rastrear en qué secuencia de números aleatorios están todos los clientes, y unir ese número con el enviado por el cliente.

El cliente también deberá registrarse para tener acceso al servidor. Esto también serviría como un mecanismo de autenticación.

Así:

//Client code: 
$sequence = file_get_contents('sequence.txt'); 
$seed = file_get_contents('seed.txt'); 
$sequence++; 

//Generate the $sequence-th random number 
srand($seed); 
for ($i = 0; $i <= $sequence; $i++) { 
    $num = rand(); 
} 
//custom fetch function 
get_info($main_url . '?num=' . $num . '&id' = $my_id); 

Esto generará una similar a esta solicitud:

http://webservice.com/get_info.php?num=3489347&id=3

//Server Code: (I'm used to PHP) 

//Get the ID and the random number 
$id = (int)$_REQUEST['id']; 
$rand = (int)$_REQUEST['num']; 
$stmt = $db->prepare('SELECT `sequence`, `seed` FROM `client_list` WHERE `id` = :id'); 
if ($stmt->execute(array(':id' => $id)) { 
    list($sequence, $seed) = $stmt->fetch(PDO::FETCH_ASSOC); 
} 
$sequence++; 

//Generate the $sequence-th random number 
srand($seed); 
for ($i = 0; $i <= $sequence; $i++) { 
    $num = rand(); 
} 
if ($num == $rand) { 
    //Allow Access 
} else { 
    //Deny Access 
} 

Mediante el uso de AA semilla diferente para cada cliente, se asegura de que los piratas informáticos no pueden predecir un número al azar mediante el seguimiento de los números anteriores utilizados.

1

Aquí hay una idea: envíe la ID del dispositivo junto con las solicitudes de su aplicación.

Monitoree los ID del dispositivo utilizados: si ve un montón de solicitudes de diferentes IP cerca o al mismo tiempo, ese dispositivo probablemente se está utilizando como una clave fija en las solicitudes que se le envían, bloquéelo. Para quienes realmente envían el ID de dispositivo real de otras aplicaciones (no la suya), puede monitorear las tendencias de uso para ver si las llamadas coinciden con el patrón de rendimiento de la aplicación, como una llamada utilizada por un dispositivo antes de algunas llamada de inicialización que normalmente esperaría, y así sucesivamente - bloquee esos también.

Básicamente, al poder cambiar las reglas en cuanto a patrones de uso, puede ajustarse mejor a alguien que intenta usar su servicio asegurándose de que no sea un objetivo fijo como lo sería una clave de uso aleatorio.

Es posible que también desee utilizar una clave de uso simple, así como una primera línea de defensa, y luego aplicar el enfoque de análisis de tráfico. También los valores de encabezado http personalizado que buscas son otra manera simple de tropezar con un atacante ingenuo.

Cuestiones relacionadas