Euristica per identificare CSRF dal file di registro di accesso Web

Question

Euristica per identificare CSRF dal file di registro di accesso Web

#1 da (0 voti)

0

Sono nuovo qui in sicurezza.

Desidero identificare gli utenti sospetti sull'applicazione Web analizzando il file di registro di accesso Web. Per questo, sto prendendo in considerazione l'attacco CSRF.

A tale scopo, sto generando alcune regole euristiche (possibili) per l'identificazione di utenti sospetti dal log web. Non sono sicuro ma ho ancora indovinato alcune regole,

Nel registro web,

1. L'URL del referrer è vuoto o non è uguale al nome di dominio dell'URL richiesto.

per es.

192.168.4.6   [10/Oct/2007:13:55:36 0700] "GET /trx.php? amt=100&toAcct=12345 HTTP/1.0" 200 4926
"http://www.attacker.com/freestuff.php" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"

Qui sono importanti due campi, l'URL richiesto ( /trx.php? amt=100&toAcct=12345 ) e il referer (" http://www.attacker.com/freestuff.php "). Di solito, il referer è un URL dello stesso sito ( www.bank.com ). Ecco un esempio di frammento di perl, come potrebbe essere rilevato:

# assuming $referer is set with the, well, referer
if ( ( $referer ne '' ) && ( $referer !~ /^https?:\/\/www.bank.com\/(login|overview|trx)\.jsp/ ) ) 
{
    # handle XSRF attack
    print(“XSRF attack: $referer\n”);
}

2. Se lo stato HTTP è 403 , ad esempio Accesso negato

(Se il token CSRF non viene inviato o se viene inviato un token CSRF non valido in richieste che richiedono un token CSRF). Quindi, qui sarà incluso il controllo dello stato 403. Perché il token non può essere controllato nel file di registro.

3. Misurando la differenza di tempo delle richieste di un utente.

Se non ci sono stati input da parte dell'utente per diversi minuti e poi improvvisamente arrivano alcune richieste di trasferimento, potrebbe essere un indicatore che questa richiesta è stata attivata da qualcosa / qualcun altro. Qui, sarà necessario controllare la differenza di tempo fino al valore di soglia dallo stesso indirizzo IP. (Insieme a questo, se i valori sono presenti dopo il simbolo ? e se questi sarebbero "pass", "password", "importo", 'amt', 'denaro', o qualsiasi link e se lo stato di richiesta dell'Utente sarebbe 200 cioè riuscito o OK).

4. Richiesta POST multipla (ripetizione) anche da singolo indirizzo IP risultati in CSRF.

Metodi idempotenti e applicazioni web I metodi PUT e DELETE sono definiti come idempotenti, il che significa che più richieste identiche dovrebbero avere lo stesso effetto di una singola richiesta (notare che idempotent si riferisce allo stato del sistema dopo che la richiesta è stata completata, quindi mentre l'azione prende il server (es. cancellazione di un record) o il codice di risposta che restituisce potrebbe essere diverso sulle richieste successive, lo stato del sistema sarà lo stesso ogni volta [citazione necessaria]). I metodi GET, HEAD, OPTIONS e TRACE, essendo prescritti come sicuri, dovrebbero anche essere idempotenti, poiché HTTP è un protocollo stateless.

Al contrario, il metodo POST non è necessariamente idempotente e pertanto l'invio di una richiesta POST identica più volte può ulteriormente incidere sullo stato o causare ulteriori effetti collaterali (come le transazioni finanziarie). In alcuni casi ciò potrebbe essere auspicabile, ma in altri casi ciò potrebbe essere dovuto a un incidente, ad esempio quando un utente non si rende conto che la sua azione comporterà l'invio di un'altra richiesta, oppure non ha ricevuto un feedback adeguato che la sua prima richiesta è stata riuscito. Sebbene i browser Web possano mostrare finestre di avviso per avvisare gli utenti in alcuni casi in cui il ricaricamento di una pagina può inviare nuovamente una richiesta POST, generalmente è compito dell'applicazione Web gestire casi in cui una richiesta POST non deve essere inviata più di una volta. / p>

5. Un sito web potrebbe consentire la cancellazione di una risorsa tramite un URL come http://example.com/article/1234/delete , che, se arbitrariamente recuperato, anche usando GET, cancellerebbe semplicemente l'articolo. (Non so cosa fare qui)

Lo so, l'identificazione CSRF dal file di registro è difficile, quindi, sto citando i possibili modi (ad esempio l'euristica) qui. Se sbagliato, è necessaria la correzione in questo. Altre regole / aiuto sarebbero apprezzate.

csrf log-analysis

posta Shree 18.12.2018 - 17:21

fonte

1 risposta

Leggi altre domande sui tag csrf log-analysis

Aggiungi i token CSRF per formare automaticamente i tag: Spring Airodump-ng: perché il BSSID non è associato?

score 0 · Answer 1

Comprendo che stai cercando di conteggiare / analizzare richieste cross-site maligne in base ai log.

Tecnicamente parlando, una richiesta cross-site è una richiesta emessa dal browser di un utente reale mentre l'utente sta interagendo con un sito Web diverso . Talvolta sono buone e dovrebbero essere attivate dalle intestazioni HTTP "cross site resource sharing" (CORS). Se non vuoi che ciò accada, assicurati che le intestazioni CORS siano corrette; dicono a il browser dell'utente per impedire ad altri siti web di fare richieste ai tuoi.

In pratica, un sacco di traffico robotico assomiglierà al traffico tra i siti nei log. Uno script in esecuzione sul mio server cloud che esegue la scansione del tuo sito per risorse non protette è vagamente come un annuncio javascript maligno che tenta di dirottare le sessioni di autenticazione basate sui cookie.

I token CSRF possono ostacolare entrambi i comportamenti sopra; sembra che tu abbia già configurato.

Esaminiamo a turno la tua euristica.

Ispezionare il campo Referer probabilmente non è utile. Vuoi che le persone siano in grado di inserire manualmente gli URL (anche se solo poche persone lo fanno, è comunque importante). Vuoi anche che le persone siano in grado di collegarsi da altri siti. Per le pagine in cui queste cose non dovrebbero essere consentite, le protezioni CSRF in tempo reale dovrebbero dare il via.
Questo se una regola di ricerca fine iff sei sicuro che non ci siano altre regole nel tuo sistema che potrebbero causare una risposta 403. Se il conteggio dei dinieghi CSRF è una priorità, probabilmente potresti dare loro il proprio codice di risposta. I codici 418 o 420, o qualsiasi 4xx non elencato qui andrebbero bene, ma la tua analisi attuale potrebbe non giustificare il tweaking del configurazione del server in questo modo.
Non sono sicuro di aver compreso i dettagli di ciò che stai proponendo qui, ma in generale non presumo che gli utenti reali non prendano lunghe pause nelle loro interazioni con il tuo sito.
Le richieste POST di duplicazione sono importanti, ma probabilmente un problema separato dalle richieste cross-site.
Il sistema su cui stai lavorando tuo ? Il comportamento che descrivi in questo articolo è certamente possibile, ma non è tipico. Allo scopo di identificare gli attacchi CSRF, non mi preoccuperei di questo a meno che tu non sappia già che è possibile sul tuo sistema o sai già che un utente malintenzionato lo sta provando contro di te.

Se stai cercando in modo specifico per richieste di cross-site errate:

Assicurati che le intestazioni CORS siano configurate correttamente per evitare richieste e assicurati che i token CORF siano sufficienti per la tua applicazione. Quindi cerca per risposta HTTP come descritto al punto 2 sopra. Se 403 non è specifico per negazione CSRF e non si desidera utilizzare un codice diverso, è possibile filtrare out le altre istanze di 403 utilizzando l'euristica per quelle casi.

Se stai cercando il traffico di robot:

È possibile ispezionare l'intestazione User-Agent. Non sono stato in grado di trovare elenchi di robot comuni di aspetto moderno, ma la ricerca aperta in questa risposta è probabilmente buono.

Se stai cercando cattivo traffico di robot:

Benvenuto nella corsa agli armamenti! Un attaccante dedicato, come minimo, sarà in grado di far sì che i loro robot facciano qualsiasi cosa che un utente umano sarebbe in grado di fare, e se questo è tutto ciò che stanno facendo, non sarai mai in grado di distinguere. Detto questo, ci sono alcune cose che puoi tenere d'occhio:

Un sacco di 404, 403 o altri errori in rapida successione o dagli stessi IP.
Il traffico da un indirizzo IP ad un ritmo più veloce di quello che un utente umano potrebbe realisticamente causare.

Tu troverà il traffico da "attaccanti". Non farti prendere dal panico, forse non ti preoccupare nemmeno di questo. Se sei impostato per negare loro quello che cercano, allora non stanno causando alcun problema. (Tranne forse per il dosaggio, nel qual caso potresti esaminare un limitatore di velocità.)