2012-01-20 13 views
13

Tengo un servicio REST que está razonablemente completo y se usará con una aplicación iOS. Está construido con Ruby/Sinatra, pero no creo que realmente importe aquí.¿Cómo proteger la parte 'pública' de un servicio REST del correo no deseado?

Estoy utilizando Autenticación HTTP básica sobre SSL para varios puntos finales y esa parte funciona muy bien.

La pregunta es: ¿Cómo evito que los spammers, etc. llamen a partes del servicio REST que no están protegidas a través de la Autenticación básica HTTP?

Ejemplo: Registro de Usuario

Vamos a suponer que la llamada resto es (POST).../register_account pasando un objeto JSON en el cuerpo.

Por razones obvias, esta llamada no puede esperar un nombre de usuario/contraseña vinculado a una cuenta de usuario.

ideas son:

1) La aplicación tiene su propio 'nombre de usuario'/contraseña y algunas llamadas comprobaría para app-credenciales. Problema: Rootear el dispositivo, etc. podría desenterrar esas credenciales.

2) La aplicación pasa un token secreto a través de un encabezado HTTP al servicio REST para esas llamadas. Problema: Igual que (1)

¿Hay alguna técnica comúnmente utilizada para evitar tales llamadas no deseadas? Estoy pensando en introducir la identificación del dispositivo del iPhone en la mezcla, pero aún no he identificado un enfoque definitivo.

Gracias

Respuesta

5

Si bien el código específico de la aplicación es una buena idea para una primera línea de defensa contra el correo no deseado, aún debe implementar algún límite en los servicios que le preocupan.

Por ejemplo, si utiliza sesiones en sus servicios REST, puede limitar fácilmente la cantidad de llamadas que procesa desde una sola sesión. La sesión no tiene que estar autenticada en absoluto y solo se usa para identificar a un solo cliente mientras realiza las solicitudes. Una simple redirección al servicio solicitado si intentan conectarse sin una sesión abierta es todo lo que se necesita, y prácticamente todos los marcos web o pilas lo tienen incorporado.

También puede limitar la velocidad en otras propiedades, como Huella digital de IP o agente de usuario, pero esos son menos confiables que un método basado en sesiones.

+0

Usaré esta joya: https://github.com/datagraph/rack-throttle para limitar la velocidad. Voy a crear una subclase para que el identificador del cliente sea un combo de id. De dispositivo + dirección IP. También se aferrará a la idea de credenciales de la aplicación. – Riaz

-2

Usted podía direcciones IP de seguimiento utilizando request.ip y escribir algo de lógica alrededor de eso.

+0

Incorrecto; hay muchas personas detrás de los NAT, por lo tanto, grandes grupos de solicitudes no correlacionadas pueden provenir de una única IP. – mbq

+1

cierto. pero podría combinar el ID del dispositivo móvil/tableta y el IP en un hash para generar un token único para compararlo con – Riaz

3

En general, un enfoque común es la clave de API, que es la misma que la ficha secreta que usted describe arriba. Puede codificarlo en su aplicación y dificultar la ingeniería inversa (ocultarla, crearla desde varias partes almacenadas en diferentes lugares dentro de su aplicación, etc.). Tiene razón en que un atacante determinado podrá recuperar la clave (si su aplicación puede hacerlo, alguien más con acceso a su aplicación también puede) ... pero puede hacerlo más difícil donde, con suerte, no lo haría No vale la pena el tiempo y el esfuerzo para hacerlo.

También podría considerar implementar SSL mutuamente autenticado, para que su servidor solo acepte las conexiones entrantes desde su aplicación y su aplicación solo se comunicará con su servidor.

Aquí está el enfoque de alto nivel. Cree un certificado SSL de servidor autofirmado e impleméntelo en su servidor web. Luego, cree un cliente autofirmado e impleméntelo dentro de su aplicación como recurso. Configure el servidor para que requiera autenticación SSL del lado del cliente y solo acepte el certificado del cliente que haya generado. Configure el cliente para que use ese certificado del lado del cliente para identificarse y solo acepte el certificado del lado del servidor que instaló en su servidor para esa parte del mismo.

Si alguien/algo además de su aplicación intenta conectarse a su servidor, la conexión SSL no se creará, ya que el servidor rechazará las conexiones SSL entrantes que no presenten el certificado del cliente que ha incluido en su aplicación.

Cuestiones relacionadas