In che modo Google Analytics previene attacchi di dati falsi contro il traffico di un'entità?

Question

In che modo Google Analytics previene attacchi di dati falsi contro il traffico di un'entità?

#1 da (6 voti)
#2 da (1 voti)

11

Per registrare un "hit" su Google Analytics, l'elenco delle cose richieste è:

Chiavi API uniche per Google Analytics
- Pubblico : può essere ottenuto dai file JavaScript incorporati nelle pagine per il tracciamento.
Richieste HTTP che sembrano provenire dalla pagina in questione.
- Può essere falsificato in una moltitudine di modi: il che significa rilevarlo e interromperlo è abbastanza difficile da non valerne la pena.
Dati JSON che rappresentano il traffico, in uno schema previsto da Google.

Fermami qui se ho sbagliato con la lista.

Se non lo sono, allora è davvero facile spoofare il traffico su un sito e rendere Google Analytics di qualcuno davvero bello anche se non riceve traffico!

In che modo Google previene questi attacchi? Non danneggia la credibilità delle statistiche di Analytics?

Sono interessato a questo a causa di un'altra domanda che sto ancora cercando di formulare con Alice, Bob, Mary e alcune chiavi private che in qualche modo devono essere sicure al pubblico. Spero che Google possa aver risolto il problema cercando di risolvere il problema questo . Inserirò un link qui una volta che avrò quella domanda.

google spoofing

posta Aditya M P 01.12.2015 - 03:14

fonte

2 risposte

Leggi altre domande sui tag google spoofing

Quale shell binario dovrei usare per l'account root su un sistema Linux? Sta usando stack separati per gli indirizzi di ritorno e gli argomenti delle funzioni una misura di sicurezza valida?

score 6 · Answer 1

In definitiva separare i dati reali dal falso è quasi impossibile, ma oltre alle misure che hai elencato, Google impiega le blacklist. È probabile che questo problema non scompaia mai.

Leggi questa domanda per maggiori informazioni. link

score 1 · Answer 2

Come notato in precedenza, non esiste un modo reale per non consentire l'invio di dati falsi. Tuttavia, nel caso in cui tu abbia accesso a entrambi i server (sito web tracciato + servizio di tracciamento), puoi renderlo "a prova di proiettile".

Dal sito Web tracciato prima di visualizzare la pagina all'utente, generare un hash casuale nella sua sessione e mostrare l'hash insieme all'ID di sessione come semplici variabili JS, che verrebbero quindi inviate con il solito oggetto traccia al servizio di tracciamento .

A sua volta, il servizio di tracciamento, prima di scrivere l'oggetto ricevuto nel DB, dovrebbe fare una richiesta addizionale al sito web con l'ID di sessione, chiedendo qual è l'hash casuale al suo interno? Se l'hash corrisponde, è una richiesta valida e può essere inserita nel DB.

Gli svantaggi qui sono che il servizio di analisi dovrebbe avere molte richieste e con questa convalida raddoppierà. Questo potrebbe anche essere evitato nel caso in cui entrambi i servizi si trovino sullo stesso server o abbiano una directory condivisa in cui sono conservati i file di sessione.

Se questo non è il caso, per ridurre il carico e il tempo della richiesta di convalida, sul sito Web tracciato, creare un file .php molto piccolo che non farebbe altro che ricevere la richiesta con l'ID di sessione e l'hash casuale, aprire il file di sessione / archiviazione e fare la convalida. Nessuna connessione DB o altro dovrebbe essere necessario per questo scopo.

Aggiornamento: Inoltre, quando si genera e sostituisce per ogni pagina un nuovo hash casuale nella sessione, se l'utente aprirà più di una scheda, sarà valido solo l'hash dell'ultima scheda. Per risolvere il problema potresti riutilizzare lo stesso hash per un certo periodo di tempo, o meglio, creare un pool (elenco) di hash validi nella sessione (ovvero 3-4 massimo) che permetteranno fino a 3-4 schede aperte tracciate in parallelo.