Encriptando la respuesta de la API en una aplicación de una sola página

Como lo entiendo bien, tienes un sitio web que sirve algunos datos y simplemente quieres evitar que los usuarios lo aprovechen.

La última vez que abordé este problema de la siguiente manera:

1. Recopile el registro de operaciones en la base de datos, lo que es bueno para almacenar registros. Algo horizontalmente escalable. Recopile toda la información que pueda, por lo que no es típico el registro HTTP sino el registro detallado, idealmente de forma estructurada.
2. Analice los registros e intente aislar a los usuarios que hacen mal uso del servicio
3. Bloquear a los usuarios que hacen mal uso del servicio

Este es un método bastante difícil pero muy efectivo, y también hay otras formas que se pueden usar con él, vea a continuación.

Básicamente, toma estos registros e intenta "comprimirlos" de la forma en que se produce algún tipo de informe con resúmenes. Dicho informe contiene solicitudes por hora durante, por ejemplo, Miércoles, variedad de datos solicitados, duración de la actividad, p. Ej. de 9 a.m. a 5 p.m. y así. Sawmill produce informes similares, así que es bueno echarle un vistazo. Cuantos más datos tenga, menos falsos positivos y mejor detección tendrá. Lo principal de esto es que se ejecuta periódicamente, por lo que, por ejemplo, podría estar procesando los registros de la forma en que solo imprime los resultados diariamente y los almacena en la base de datos como informes que se generan por usuario por día, y luego puede producirlos semanalmente. Informes mensuales y anuales, y de esta manera puede decir con precisión quién está haciendo un mal uso.

Creo que es mejor limitar la cantidad de solicitudes por minuto / hora / día. Esto se puede hacer usando otra base de datos como Redis, por ejemplo. Si se excede el límite, simplemente devuelva el error relevante. Piense como "métricas en tiempo real". Si supera cierto umbral de solicitudes totales por período, simplemente se bloqueará.

Otra idea es utilizar invitaciones. Como lo hizo Google Mail en el pasado. De esta manera es más fácil rastrear a los usuarios malintencionados.

Otra cosa sería centrarse en la seguridad de la cuenta. Para asegurarse de que los usuarios son reales (como la confirmación del número de teléfono como en el pago de Facebook o CC) y que las cuentas no se comparten, por ejemplo. utilizado por dos personas al mismo tiempo.

En cuanto a la confusión de datos, es un buen enfoque ya que efectivamente limita la cantidad de actores maliciosos. Una de las formas de hacerlo es cambiar los algoritmos con frecuencia o incluso codificarlos por adelantado y cambiarlos automáticamente cada mes. La forma en que no se puede automatizar. Sin embargo, tenga en cuenta que hay herramientas como PhantomJS que pueden actuar como un navegador normal y hacer eso de todos modos. Por lo tanto, tal vez también se necesite algo de Captcha cuando alcanzas cierto límite.

También puede cambiar el formato de la base de datos de vez en cuando, como las respuestas json.

Y con respecto a los usuarios, puede solicitarles que inicien sesión a través de la cuenta de Google, por ejemplo, para que sea más fácil que revisarlos por su cuenta, al igual que con Facebook.

Y no olvides incluir el EULA. Y en T & C escribe claramente lo que está permitido y lo que no.

Su API debería verificar quién está haciendo la llamada y realizar cualquier tipo de restricciones en el lado del servidor.

La forma de lidiar con esto es implementar la autorización del lado del servidor y mitigar contra referencia de objeto de seguridad y control de acceso a nivel de función . Estos deberían ser estándar de todos modos.

Si su API devuelve información que no desea que la persona que llama pueda ver, implementó la API incorrectamente. No hay nada que pueda hacer para proteger los datos en ese momento, ya que el usuario final puede simplemente monitorear el tráfico de la red utilizando algo como la consola Chrome. Incluso si lo cifra, el código para descifrarlo se encuentra en el navegador del usuario final y se puede realizar ingeniería inversa. Supongo que podría retener la clave a todos excepto a los usuarios autorizados, pero ¿cuál es el punto de usar el ancho de banda al devolver datos que no se pueden leer? En lugar de cifrarlo, también puede redactarlo, por ejemplo. Reemplácelo con un alboroto completamente al azar, o reemplácelo con cadenas vacías. Hazlo del lado del servidor.

Un navegador web no es una plataforma DRM, punto final.

El estado de la técnica en esta área general son las técnicas de distribución de malware y la ofuscación de javascript. Google es la mejor fuente para las últimas noticias, este espacio cambia rápidamente.

En comparación con el estado de la técnica, las técnicas mencionadas en la pregunta no desviarían a un analista experto interesado en recuperar sistemáticamente los datos que están disponibles durante más de un par de días. El paso por el código del lado del cliente con un depurador revela los secretos deseados muy rápidamente.