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

Tengo que diseñar un "widget", un script que los socios incorporarán en sus sitios web para mostrar una interfaz de usuario y realizar llamadas a nuestra API.

Básicamente, mostrará nuestros datos en estos sitios en función de algunos ID que proporcionan en nuestras llamadas a la API. Lo que nos gustaría evitar es que alguien esté abusando de la API y usándola para raspar la totalidad de nuestro catálogo.

Cada socio que incorpore nuestro script recibirá una clave pública que debe proporcionarse al llamar a la API. Una idea sería pedirles que agreguen esta clave al cargar el script, por ejemplo:

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

De esa manera, la solicitud del script se puede utilizar para registrar el par de IP clave / fuente y responder las llamadas API posteriores solo si el par de clave / IP 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 a través de la ofuscación (alguien que vuelva a cargar el script lo omitirá por completo); pero no veo otra forma de restringir el acceso. No puedo proporcionar una clave única para cada usuario, solo para los socios. No puedo usar un sistema de clave privada ya que todo el código estará disponible para cualquiera. Básicamente está restringiendo el acceso a una API pública, es decir, contradictoria en su definición.

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

Necesita 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 refererencabezado, pero debido a que su cliente está incrustando un script directamente, puede confiar razonablemente en el document.locationlado 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_keyen la solicitud de la biblioteca API.
2. El servidor determina el host que tiene acceso a la API, si corresponde.
3. El servidor selecciona "salt" para una clave de sesión y la envía al cliente con la biblioteca [o como parte de otro intercambio previo a la autenticación].
4. El cliente calcula un session_keyuso hash(document.location.host + session_salt).
5. El cliente usa session_key+ client_keypara una llamada API.
6. El servidor valida la llamada buscando el client_keyhost y la "sal" de la sesión, calculando el hash y comparándolo con el proporcionado client_key.

En segundo lugar , debe impedir que Hacker Hank abra la consola de depuración o use 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 limitar la 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 un tráfico sostenido 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 tráfico pesado sostenido de una sola IP.

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

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

Los chicos de seguridad con los que trabajo usualmente descartan la dirección IP porque IP es falsificable. Pero si está utilizando una restricción de IP combinada con SSL, eso generalmente funciona.

Pero debe "incluir en la lista blanca" las direcciones IP; de lo contrario, cualquier hacker puede entrar por la puerta principal.

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

En mi humilde opinión ... Pero si solo está tratando de proteger la información de propiedad de la compañía en lugar de la tarjeta de crédito (PCI) o la información personal / privada (PII), entonces esto probablemente sea bueno incluso sin SSL, dependiendo de cuánto dispuesto a arriesgarse a exponer su catálogo.

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

Estoy tratando de pensar en una forma de prescindir de la lista blanca de IP porque eso suele ser difícil de manejar;) sin ir a OAuth en toda regla. Voy a fideos en eso.