Dispari richieste HTTP "duplicate"

2

Un'operazione HTTP GET duplicata imprevista ha attivato un rapporto "evento insolito" sul mio sito web. Il duplicato è venuto dal sito web di "Trendmicro.com" che sembra essere nel settore della sicurezza di Internet. È solo una mia supposizione, ma sospetto che raccolgano query di esempio per conto dei loro clienti, quindi inviano loro stesse tali query ed eseguono una sorta di analisi sui risultati.

Questo di solito è innocuo, ma mi chiedo quali sarebbero le implicazioni per il traffico che è destinato ad avere effetti collaterali, se il server non è consapevole che potrebbe apparire un'altra richiesta simile.

Ad esempio, nel mio caso in esame la richiesta era intesa ad aggiornare un database di classificazione degli utenti e il duplicato ha attivato un avviso di hacking. Senza il controllo, l'aggiornamento si sarebbe verificato due volte.

modifica: è anche rilevante che la richiesta "originale" sia originata da un IP in Australia, e che il "Duplicato" sia arrivato pochi secondi dopo da un IP localizzato a San Francisco. Ci sono state un centinaio di richieste HTTP nella sessione, ma solo 2 o 3 sono state duplicate.

    
posta ddyer 26.07.2013 - 20:23
fonte

3 risposte

4

Trend Micro è un giocatore abbastanza grande nella sicurezza (almeno ne ho sentito parlare).

Uno dei loro prodotti è una barra degli strumenti del browser per avvisare gli utenti di siti Web dannosi. Sono d'accordo con la tua ipotesi, che stanno recuperando pagine che la loro barra degli strumenti ha visto prelevare dagli utenti, in modo che possano decidere se è dannoso.

Qui ci sono alcune informazioni sul ragno di Trend Micro: link

Idealmente avrebbero solo rigiocare le richieste GET e le richieste GET dovrebbero essere idempotenti (non avere effetti collaterali). Se i tuoi dati utente vengono modificati come risultato di una richiesta GET, ti consiglio di cambiarla in POST. Non solo il robot Trend Micro, ma qualsiasi robot o motore di ricerca spider potrebbe arrivare e fare un GET su qualsiasi link e causare un risultato indesiderato.

    
risposta data 28.07.2013 - 14:08
fonte
3

Il problema dipende totalmente da ciò che il server intende fare. Un "replay attack" è un approccio vecchio e abbastanza valido per attaccare quasi ogni sistema o protocollo. Aumentare il punteggio di un utente è un buon uso, poiché cambierebbe sicuramente lo stato del sistema e servirebbe a beneficio di qualcuno. L'acquisto di due ordini sulla carta di credito di qualcuno sarebbe anche peggio!

È qualcosa che dovrebbe essere preso in considerazione nella progettazione di un sistema. Cose che ho visto usate come preventive:

  • timeout prima di ripetere: il sistema fa in modo che un determinato account attenda un certo periodo di tempo prima di ripetere un'azione (Stack Exchange lo ha fatto in alcuni punti)
  • richiede un nonce, quando vengono utilizzate le firme digitali. - se chiedi di fare un aggiornamento, il mio server ti fornisce un pezzo unico di dati privi di significato, invii la tua richiesta e i dati e firmi tutto. Non ti permetterò di inviare lo stesso peice di dati privi di significato due volte: devi chiedere, firmare, inviare più e più volte che richiede che le credenziali dell'utente siano disponibili.
  • privacy punto a punto - mantiene l'uomo in mezzo
risposta data 26.07.2013 - 21:13
fonte
3

L'indizio qui è dove dici di aver ricevuto una richiesta di GET duplicata. Il resto della tua domanda mi ha quasi messo fuori strada, pensando a qualche client (o un altro server per suo conto per qualsiasi motivo) richieste duplicate di POST , o persino intestazioni di richieste complete duplicate (cookie, e.t.c.). Ma quello che descrivi potrebbe anche essere letto come "lo stesso URL è stato richiesto" .

Ad ogni modo, il motivo più comune per le richieste duplicate di GET provengono da quelli che sono conosciuti come proxy di cache . Alcuni di questi prodotti possono essere rilevati apparentemente senza alcun supporto per la compressione ( gzip , deflate , ...) mostrati nei registri come richieste duplicate ma la dimensione della risposta sarà maggiore, come ProxySG di Blue Coat System (apparentemente uno dei più grandi player nel settore delle appliance proxy). Altri potrebbero modificare User Agent string di conseguenza per identificarsi agli amministratori del Web leggendo registri di accesso, firewall di applicazioni Web, ecc. E alcune richieste di ripetizione completamente sinonime alle richieste originali e solo IP address potrebbe differire, anche se (se il client utilizza il proxy anche come gateway, quindi IP address rimarrà esattamente lo stesso e le richieste ripetute seguiranno le intestazioni di scadenza della cache dei contenuti richiesti).

Questi caching proxies possono essere un po 'fastidiosi a volte (si veda ad esempio questo ranting su Soluzioni Blue Coat System ), ma non sono considerate come una particolare minaccia alla sicurezza. Beh, almeno non in modo diverso rispetto a tutti gli altri proxy - alla fine della giornata, sono Uomini in Gli host centrali e non attendibili possono essere considerati estremamente rischiosi da utilizzare per gli utenti finali. Ma molte reti le usano per vari motivi, come la memorizzazione nella cache locale per ridurre le esigenze di larghezza di banda per gli host remoti, accelerare i tempi di risposta, persino memorizzare più vecchie copie dei documenti accessibili per l'accessibilità. E in un certo senso, Google è il più grande proxy che conosciamo. Quello che sto dicendo è che non vi è alcuna indicazione che la richiesta che descrivesti sia stata duplicata con intenzioni malevoli, e tale richiesta di duplicazioni non dovrebbe causare alcun problema sul tuo server (oltre a un occasionale inutile consumo di larghezza di banda), se le tue applicazioni web sono scritte correttamente, per autorizzare nuovamente gli utenti ogni volta che è necessario e utilizzare altri mezzi per identificare i singoli utenti rispetto ai parametri GET della richiesta di URI (come cookies , i proxy di caching non dannosi non devono allegare alle loro richieste duplicate per la memorizzazione nella cache scopi).

Non sto dicendo che quello che è successo non è stato un tentativo malevolo, quello che sto dicendo è che ciò che descrivi non lo dimostra in alcun modo, e potrebbe anche essere stato un ospite benigno della varietà proxy di cache.

    
risposta data 26.07.2013 - 21:16
fonte

Leggi altre domande sui tag