2009-11-19 19 views
11

Me preguntaba si alguien había encontrado alguna técnica para reducir las posibilidades de que los datos expuestos a través de servicios tipo JSON en el servidor (destinados a proporcionar funciones AJAX) sean recolectados por agentes externos .Técnicas para reducir la recolección de datos de los servicios AJAX/JSON

Me parece que el problema no es tan difícil si dijeras que un cliente Flash consume los datos. Luego, podría enviar datos cifrados al cliente, que sabría cómo descifrarlos. Sin embargo, el mismo método parece imposible con AJAX, debido a la naturaleza abierta de la fuente Javascript.

¿Alguien ha implementado una técnica inteligente aquí?

Sea cual sea el método, todavía debe permitir que una función AJAX genuina consuma los datos.

Tenga en cuenta que realmente no estoy hablando de proteger la información 'sensible' aquí, el registro impar que se escapa no es un problema. Más bien, estoy pensando en detener una situación en la que toda la base de datos es atrapada por bots (ya sea de una vez, o gradualmente con el tiempo).

Gracias.

Respuesta

7

En primer lugar, me gustaría aclarar en esto:

Me parece que el problema no es tan difícil si tiene que decir un flash cliente consumidor de los datos. Entonces podría enviar datos cifrados al cliente , que sabría cómo descifrarlo. El mismo método parece imposible con AJAX, debido a naturaleza abierta de la fuente Javascrip .

Será bastante obvio que la información se envía encriptada al cliente Flash & no va a ser tan difícil para el atacante averiguar a través de su programa flash lo que está siendo utilizado para este compilado - replicar & obtener todos esa información

Si los datos tienen el valor que está pensando, puede contar con lo anterior.

Si esto es información pública, abrazo que & no lo combata, en su lugar, encuentre la forma de capitalizarlo.

Si esta es la información que solo está exponiendo a un conjunto de usuarios, asegúrese de tener la correspondiente autenticación/comunicación segura. Rastree el uso como otros lo han dicho, y tenga medidas que actúen sobre él,

+2

"Si se trata de información pública, acepte eso y no lo combata, en su lugar, encuentre formas de capitalizarlo". +1 –

+0

Sí, esa oración solo merece un +1. – anddoutoi

1

Si tiene un cuadro Memcached interno, podría considerar utilizar una técnica en la que cree una entrada para cada IP que llegue a su servidor con una hora de vencimiento. Luego incremente ese valor cada vez que el IP llegue a su punto final AJAX. Si el valor supera un umbral en particular, freír la conexión. Si el valor expira en Memcached, sabrá que no se está "alejando".

1

Esta no es una respuesta concreta con una prueba de concepto, pero tal vez sea un punto de partida para usted. Puede crear una función de JavaScript que proporcione funciones de cifrado/descifrado. El javascript necesitaría ser construido dinámicamente, e incluiría una clave de encriptación que es única para la sesión. Del lado del servidor, tendría un servicio de encriptación que usa la clave de la sesión para encriptar su JSON antes de entregarlo.

Esto al menos evitaría que alguien escuche el tráfico de su web, sacando información de su base de datos.

Aunque estoy con kdgergory, parece que sus datos están demasiado abiertos.

7

Lo primero para evitar que los robots roben sus datos no es tecnológico, es legal. En primer lugar, asegúrese de tener el lenguaje correcto en los Términos de uso de su sitio, ya que lo que está tratando de evitar no está permitido y es defendible desde un punto de vista legal. En segundo lugar, asegúrese de diseñar su estrategia técnica teniendo en cuenta los problemas legales. Por ejemplo, en los EE. UU., Si coloca los datos detrás de una barrera de autenticación y un atacante se la roba, es probable que sea violation of the DMCA law. En tercer lugar, busque un abogado que pueda asesorarlo sobre cuestiones de IP y DMCA ... gente amable en StackOverflow no es suficiente. :-)

Ahora, acerca de la tecnología:

Una solución razonable es requerir que los usuarios sean autenticados antes de que puedan acceder a su Ajax sensibles llama. Esto le permite simplemente monitorear el uso por usuario de sus llamadas Ajax y (manual o automáticamente) cancelar la cuenta de cualquier usuario que haga demasiadas solicitudes en un período de tiempo particular. (o demasiadas solicitudes totales, si está tratando de defenderse contra un enfoque lento).

Este enfoque, por supuesto, es vulnerable a bots sofisticados que automáticamente registran nuevos "usuarios", pero con una implementación de CAPTCHA razonablemente buena, es bastante difícil construir este tipo de bot.(Consulte la sección "elusión" en http://en.wikipedia.org/wiki/CAPTCHA)

Si está tratando de proteger los datos públicos (sin autenticación), entonces sus opciones son mucho más limitadas. Como se señaló en otras respuestas, puede probar los límites basados ​​en la dirección IP (y se encuentran en conflicto con los grandes usuarios proxy corporativos), pero los atacantes sofisticados pueden evitar esto distribuyendo la carga. También hay un software sofisticado que mira cosas como el tiempo de solicitud, patrones de solicitud, etc. e intenta detectar bots. Los sitios de poker, por ejemplo, dedican mucho tiempo a esto. Pero no espere que este tipo de sistemas sea barato. Una cosa fácil que puede hacer es extraer los registros de su sitio web (por ejemplo, usando Splunk) y encontrar las direcciones N IP más importantes que llegan a su sitio, y luego hacer una búsqueda IP inversa. Algunos serán proxies corporativos o ISP legítimos. Pero si reconoce el nombre de dominio de un competidor entre la lista, puede bloquear su dominio o hacer un seguimiento con sus abogados.

Además de pre-robo de defensa, también puede ser que desee pensar en la inserción de un "tarro de miel": deliberadamente información falsa que puede realizar un seguimiento posterior. Así es como, por ejemplo, los fabricantes de mapas captan el plaigarismo: insertan una calle falsa en sus mapas y ver qué otros mapas muestran la misma calle falsa. Si bien esto no impide que personas determinadas absorban todos tus datos, te permite saber más tarde quién está reutilizando tus datos. Esto se puede hacer insertando cadenas de texto únicas en el resultado de su texto, y luego buscando esas cadenas en Google más tarde (suponiendo que sus datos sean reutilizables en otro sitio web público). Si sus datos son HTML o imágenes, puede incluir una imagen que apunte a su sitio, y puede rastrear quién la está descargando, y buscar patrones que pueda usar para destruir a los expedicionarios.

Tenga en cuenta que el enfoque de cifrado javascript indicado en una de las otras respuestas no funcionará para las sesiones no autenticadas: un atacante puede simplemente descargar el javascript y ejecutarlo como lo haría un navegador normal. Moraleja de la historia: los datos públicos son esencialmente indefendibles. Si desea mantener los datos protegidos, colóquelo detrás de una barrera de autenticación.

Esto es obvio, pero si sus datos son buscables públicamente por los motores de búsqueda, ambos necesitarán una solución que no sea AJAX (Google no leerá sus datos de AJAX) y querrá marcar esos páginas NOARCHIVE para que sus datos no se muestren en la memoria caché de Google. También es probable que desee una lista blanca de direcciones IP del rastreador del motor de búsqueda que permita en las páginas rastreables del motor de búsqueda (puede trabajar con Google, Bing, Yahoo, etc. para obtenerlas), de lo contrario, los robots malintencionados simplemente podrían suplantar Google y obtén tus datos

En conclusión, quiero hacer eco @kdgregory arriba: asegúrese de que la amenaza es suficientemente real que vale la pena el esfuerzo requerido. Muchas empresas sobreestiman el interés que otras personas (tanto clientes legítimos como actores nefastos) tienen en sus negocios. Puede ser que el tuyo sea un caso extraño en el que tienes datos particularmente importantes, es particularmente valioso para obtener, debe ser de acceso público sin autenticación, y tus recursos legales estarán limitados si alguien roba tus datos. Pero todos aquellos juntos son ciertamente un caso inusual.

P.S. - Otra forma de pensar acerca de este problema que puede aplicarse o no en su caso. A veces es más fácil cambiar la forma en que funcionan sus datos, lo que evita tener que protegerlo. Por ejemplo, puede vincular sus datos de alguna manera a un servicio en su sitio para que los datos no sean muy útiles a menos que se utilicen junto con su código. ¿O puede incrustar publicidad en ella, de modo que donde sea que se muestre le paguen? Y así. No sé si alguna de estas mitigaciones se aplica a su caso, pero muchas empresas han encontrado maneras de regalar cosas gratis en Internet (y alentar en lugar de evitar una amplia redistribución) y aún así ganar dinero, por lo que un híbrido gratis/estrategia de pago puede (o no) ser posible en su caso.

+0

Es una línea muy fina entre ser extremadamente ofensivo para la comunidad técnica al citar marcos legales e intentar proteger al desarrollador. Es como si la industria discográfica fomentara la distribución de música en los años 80 y luego diera la vuelta y etiquetara a toda una generación como infractores de la ley en la década de 2000, cuando las técnicas de distribución de usuarios se vuelven sin pérdidas. Si publica datos públicos que no desea que otros vean, encerrelos, no persiga a personas con términos y condiciones después del hecho. –

+0

Acepto, la ley no es una excusa para no encontrar buenas soluciones técnicas. De hecho, tenía una situación específica en mente con mi sugerencia "legal": si un competidor determinado y bien financiado (no muchos usuarios individuales) decide robar todos sus datos, independientemente de los obstáculos técnicos que ponga, sería malo si no tuviste ninguna influencia legal para que se detengan. No quise respaldar el enfoque de la industria discográfica con respecto a este problema, o algo similar, lo siento si me encontré de esta manera. –

+0

Solo para hacerte saber: hubiera marcado esto como la respuesta aceptada, pero desafortunadamente estaba fuera de la computadora al final de la recompensa. – UpTheCreek

1

Éstos son una variedad de sugerencias:

  1. fichas cuestión requería para el rescate, junto con cada uno Solicitud de AJAX Expira los tokens.
  2. Haga un seguimiento de cuántas consultas provienen de cada cliente y acelere el uso excesivo según el uso normal esperado de su sitio.
  3. Busque patrones en el uso, como consultas secuenciales, picos en las solicitudes o consultas que ocurren más rápido de lo que un humano podría realizar.
  4. Comprobar agentes de usuario. Muchos bots no replican completamente la información del agente de usuario de un navegador, y usted puede eliminar el raspado programático de sus datos usando este método.
  5. Cambie el componente frontal de su sitio web para redirigirlo a un captcha (u otro mecanismo de verificación humano) una vez que se exceda el umbral de solicitud.
  6. Modifique su lógica para que los datos de respsonse se devuelvan de diferentes maneras para complicar el código necesario para analizar.
  7. Obscurezca su javascript del lado del cliente.
  8. Bloquea las direcciones IP de los clientes infractores.
0

Bots normalmente no analiza Javascript, por lo que su código AJAX no se ejecutará instantáneamente.Y si lo hacen, los bots generalmente no mantienen sesiones/cookies también. Sabiendo eso, puede rechazar la solicitud si se invoca sin una sesión/cookie válida (que obviamente se establece en el lado del servidor de antemano por la solicitud en la página principal).

Esto no lo protege del peligro humano. La forma más segura es restringir el acceso a los usuarios con un nombre de usuario/contraseña. Si esa no es tu intención, bueno, entonces tienes que vivir con el hecho de que es una aplicación pública . Por supuesto, puede escanear registros y listas negras maintian con direcciones IP y agentes publicitarios, pero eso es extremo.

Cuestiones relacionadas