¿Cómo evita Google Analytics los ataques de datos falsos contra el tráfico de una entidad?

Question

¿Cómo evita Google Analytics los ataques de datos falsos contra el tráfico de una entidad?

#1 de keepass_fan (5 votos)
#2 de cephuo (1 votos)

10

Para registrar un "hit" en Google Analytics, la lista de cosas necesarias son:

Clave (s) de API únicas para Google Analytics
- Público : se puede obtener de los archivos JavaScript incrustados en las páginas para su seguimiento.
solicitudes HTTP que parecen originarse en la página en cuestión.
- Se puede falsificar de muchas maneras: lo que significa detectarla y detenerla es lo suficientemente difícil como para que no valga la pena.
Los datos JSON representan el tráfico, en un esquema que Google espera.

Deténgame aquí si me equivoco con la lista.

Si no lo soy, entonces es muy fácil falsificar el tráfico en un sitio y hacer que el Google Analytics de alguien se vea realmente bien, incluso si no recibe tráfico.

¿Cómo, entonces, evita Google estos ataques? ¿No perjudica la credibilidad de las estadísticas de Analytics?

Estoy interesado en esto debido a otra pregunta que todavía estoy luchando por formular para involucrar a Alice, Bob, Mary y algunas claves privadas que de alguna manera deben ser públicas. Espero que Google haya solucionado ese problema al tratar de solucionar el problema este . Publicaré un enlace aquí una vez que tenga esa pregunta.

google spoofing

pregunta Aditya M P 01.12.2015 - 03:14

fuente

2 respuestas

Lea otras preguntas en las etiquetas google spoofing

Comunicación entre SIM, banda base y procesador de aplicaciones ¿Por qué Twitter y Facebook no aplican la complejidad de las contraseñas durante el registro? [cerrado]

score 5 · Answer 1

5

En última instancia, separar los datos reales de los falsos es casi imposible, pero además de las medidas que enumera, Google emplea listas negras. Es probable que este problema nunca desaparezca.

Revisa esta pregunta para más información. enlace

respondido por el keepass_fan 13.12.2015 - 04:57

fuente

score 1 · Answer 2

Como se señaló anteriormente, no hay una manera real de no permitir el envío de datos falsos. Sin embargo, en caso de que tenga acceso a ambos servidores (sitio web rastreado + servicio de seguimiento), puede hacerlo "a prueba de balas".

Desde el sitio web rastreado antes de mostrar la página al usuario, genere un hash aleatorio en su sesión y muestre el hash junto con el ID de sesión como variables JS simples, que luego se enviarían con el objeto de seguimiento habitual al servicio de rastreo. .

A su vez, el servicio de seguimiento, antes de escribir el objeto recibido en la base de datos, debe hacer una solicitud adicional al sitio web con el ID de sesión, preguntando qué hash aleatorio actualmente. Si el hash coincide, es una solicitud válida y se puede insertar en la base de datos.

La desventaja aquí es que se espera que el servicio de análisis tenga muchas solicitudes y con esta validación las duplicará. Esto también podría evitarse en caso de que ambos servicios estén ubicados en el mismo servidor o tengan un directorio compartido donde se guardan los archivos de sesión.

Si este no es el caso, para reducir la carga y el tiempo de la solicitud de validación, en el sitio web rastreado, cree un archivo .php muy pequeño que no haría nada más que recibir la solicitud con el ID de sesión y el hash aleatorio. Abrir el archivo de sesión / almacenamiento y hacer la validación. No se necesita conexión de DB o cualquier otra cosa para este propósito.

Actualización: Además, al generar y reemplazar por cada carga de página un nuevo hash aleatorio en la sesión, si el usuario abrirá más de una pestaña, solo será válido el hash de la última pestaña. Para resolver esto, puede reutilizar el mismo hash durante un cierto tiempo, o mejor, crear un conjunto (lista) de hashes válidos en la sesión (es decir, 3-4 máximo) que permitirá hasta 3-4 pestañas abiertas con seguimiento en paralelo.