¿Cómo evitar el uso no autorizado de una API?

7

Tengo que diseñar un "widget", un script que los socios integrarán en sus sitios web para mostrar alguna IU y hacer llamadas a nuestra API.

Básicamente, mostrará nuestros datos en estos sitios según los ID que proporcionen en nuestras llamadas a la API. Lo que nos gustaría evitar es que alguien abuse de la API y la utilice para eliminar la totalidad de nuestro catálogo.

A cada socio que incruste nuestro script se le asignará una clave pública que debe proporcionarse al llamar a la API. Una idea sería pedirles que adjunten esta clave cuando carguen el script, por ejemplo:

<script src="//initrode.com/widget/loader.js?key=xxxx"></script>

De esa manera, la solicitud del script se puede usar para registrar el par de IP de clave / fuente, y responder a las llamadas API subsiguientes solo si el par de IP / clave coincide con uno registrado (con una vida útil limitada y un límite de solicitudes por día).

No estoy seguro de que sea una buena idea, ya que obviamente es seguridad mediante ofuscación (alguien que recargue el script lo omitirá por completo); pero no veo ninguna otra forma de restringir el acceso. No puedo proporcionar una clave única para cada usuario, solo a los socios. No puedo usar un sistema de clave privada ya que todo el código estará disponible para todos. Básicamente, está restringiendo el acceso a una API pública, es decir, contradictoria en su definición.

¿Qué piensa de esta solución y qué haría con estas restricciones?

    
pregunta Antoine 21.02.2014 - 16:52

2 respuestas

12

Necesitas varios tipos de protección.

En primer lugar , debe evitar que la clave del sitio A se use en el sitio B.

En teoría, si la clave está vinculada a un dominio, no puede depender del encabezado referer , pero como su cliente está incrustando un script directamente, puede confiar razonablemente en el document.location en el lado del cliente. Enviar esa ubicación (o partes de ella) al servidor directamente no es confiable; pero puedes usarlo para generar una clave de sesión:

  1. El cliente incrusta client_key en la solicitud de la biblioteca API.
  2. El servidor determina el host que tiene acceso a la API, si corresponde.
  3. El servidor selecciona "sal" para una clave de sesión y la envía al cliente con la biblioteca [o como parte de otro intercambio de autenticación previa].
  4. El cliente calcula un session_key usando hash(document.location.host + session_salt) .
  5. El cliente usa session_key + client_key para una llamada a la API.
  6. El servidor valida la llamada al buscar el host de client_key y la "sal" en la sesión, calcular el hash y comparar con el client_key proporcionado.

En segundo lugar , debe impedir que Hacker Hank abra la consola de depuración o utilice un cliente modificado en el Sitio A para hacer lo que quiera con su API.

Sin embargo, tenga en cuenta que es muy difícil, si no imposible, evitar por completo que Hacker Hank abuse de la API. Pero, puedes hacerlo más difícil. Y la forma más razonable de impedir a Hank, que yo sepa, es la limitación de velocidad.

  • Limite el número de solicitudes / segundo / sesión y solicitudes / hora / sesión. (Los picos en la actividad son probablemente razonables, pero no mantienen el tráfico por encima del promedio de un solo cliente.)
  • Limite el número de sesiones / IP / hora.
  • Limite el número de solicitudes / IP / hora. Permitir picos, pero no sostenido tráfico pesado desde una sola IP.

En tercer lugar , como probablemente ya esté haciendo: encripte el tráfico. Claro, la NSA lo verá; pero es menos probable que Hacker Hank.

    
respondido por el svidgen 21.02.2014 - 18:11
0

Parece que lo estás haciendo aquí al convertir tus archivos javascript en recursos protegidos. Y agrupándolo con una especie de generación de tokens al mismo tiempo. Eso es interesante.

Los tipos de seguridad con los que trabajo normalmente descartan la dirección IP porque IP es falsa. Pero si estás usando una restricción de IP combinada con SSL, eso generalmente funciona.

Pero tienes que "poner en la lista blanca" las direcciones IP, de lo contrario cualquier pirata informático puede entrar por la puerta principal.

Era escéptico, pero en realidad creo que tu esquema funciona bastante bien. Si 1) el archivo .js y las subsiguientes llamadas a la API se realizan con TLS (es decir, SSL o https), y 2) las IP están en la lista blanca. Luego haré una declaración audaz y le diré que creo que aprobaría una revisión de seguridad, incluso para las interacciones de PCI (tarjeta de crédito).

IMHO ... Pero si solo está tratando de proteger la información propiedad de la empresa en lugar de la tarjeta de crédito (PCI) o la información personal / privada (PII), es probable que esto sea bueno incluso sin SSL, dependiendo de cuánto estás dispuesto a arriesgarte a exponer tu catálogo.

O dicho de esta manera: con SSL, un pirata informático dedicado no podría obtener su catálogo. (A menos que rompan SSL, pero también podrían romper Amazon). Sin SSL, un pirata informático dedicado podría detectar sus llamadas, falsificar la propiedad intelectual y desplegar su catálogo. Así que es una especie de juicio sobre el riesgo.

Estoy tratando de pensar en una manera de prescindir de la lista blanca de IP porque eso suele ser un dolor para administrar;) sin ir a OAuth en toda regla. Voy a fideos sobre eso.

    
respondido por el Rob 21.02.2014 - 17:19

Lea otras preguntas en las etiquetas