Controllo della stringa dell'agente del browser per la sicurezza dell'applicazione

Question

Controllo della stringa dell'agente del browser per la sicurezza dell'applicazione

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Recentemente ho trovato alcuni registri nella mia applicazione in cui ho visto cambiare le informazioni sull'agente del browser dell'utente. Anche se l'utente utilizza lo stesso browser, le informazioni sull'agente sono state modificate per richieste consecutive.

Ad esempio, una richiesta proveniente dall'utente proviene da

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0)

Ma l'utente non ha cambiato il suo browser e le informazioni del browser erano:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/7.0)

Se non riesco nemmeno a fare affidamento sulle informazioni sull'agente del browser, qual è il modo ideale per confermare che l'agente del browser non ha / non è stato modificato?

Problema che sto cercando di risolvere

Problema di risoluzione della sessione - Sto cercando di rilevare quando un utente fa quanto segue:

1) Grab richiede intestazioni appartenenti ad una sessione autenticata. 2) Passa a un altro computer in una posizione diversa (ad esempio computer / browser diversi). 3) Crea una nuova richiesta con le stesse intestazioni dalla sessione autenticata e riceve una risposta positiva con le risorse (ad esempio file / pagina con dati privati).

Originariamente ho provato a risolverlo con l'indirizzo IP e gli assegni dell'agente del browser, ma mi sono reso conto che, a causa del passaggio da NAT, il controllo dell'indirizzo IP è del tutto impossibile. Ora sembra che anche il controllo browser-agent non sia buono.

web-browser session-fixation

posta ha9u63ar 13.12.2016 - 11:57

fonte

3 risposte

Leggi altre domande sui tag web-browser session-fixation

Quanto è grave "AtomBombing" e AV potrebbe essere fatto per rilevarlo? Qualcuno può prelevare denaro dal mio account solo con il mio numero di Account e Routing?

score 3 · Answer 1

Non utilizzare l'agente utente per motivi di sicurezza.

Non è affidabile e facile da modificare. Come altri hanno notato, ogni browser può impostare l'agente utente su un valore arbitrario. È solo un'intestazione di informazioni che potresti decidere di inviare.
Non è privato e facilmente prevedibile. Esistono elenchi degli agenti utente più comuni . Quindi un utente malintenzionato può fare ipotesi plausibili o attirare la vittima su un proprio sito per registrare la stringa dell'agente utente e utilizzare il valore ottenuto.

Il problema che descrivi non è una vulnerabilità risoluzione della sessione . È accettabile il comportamento che la stessa richiesta autenticata funzioni da posizioni diverse. Ad esempio, quando accedi a Github puoi estrarre il cookie user_session da un browser e semplicemente usarlo su un'altra macchina. Poiché un utente malintenzionato non accede facilmente al contenitore dei cookie del browser, non si tratta di un problema di sicurezza generale.

score 0 · Answer 2

Poiché l'agente utente è facilmente modificabile ed è contenuto nelle intestazioni di cui ti preoccupi nella dichiarazione del problema, il metodo che proponi per risolvere il problema non è valido.

La tua dichiarazione del problema descrive il dirottamento di sessione, non la fissazione della sessione.

Molte persone hanno cercato di trovare soluzioni al problema; nessuno di loro è robusto. Tali soluzioni di solito si interrompono quando l'utente apre una nuova finestra, o usa il pulsante indietro - se riesci a conviverci, e c'è davvero un vantaggio netto, dai un'occhiata ai token CSRF.

Le misure preventive più importanti da proteggere contro la riproduzione / il dirottamento di sessione sono:

usa sempre TLS
assicurati di impostare i flag httponly e secure sui cookie di sessione
fornire la funzione di LOGOUT chiara ed esplicita
applica i timeout della sessione

score 0 · Answer 3

Come sapete, l'agente utente può essere modificato, manomesso, ecc. sul lato client. Quindi, puoi provare a memorizzare ips, i programmi utente e fare qualche tipo di controllo ... ma hai bisogno di un terzo fattore qui: tempo . In quante volte accetterete una connessione proveniente dallo stesso IP con un diverso user-agent? Non è facile differenziare le connessioni "natural-legal" dalle connessioni "spoffing-trying-to-hack-you-requests". Penso che non ci sia un metodo al 100% per farlo.