it-swarm.dev

Dobbiamo disconnetterci dalle webapp?

Una rapida ricerca su Google non rivela se è importante disconnettersi dalle webapp (servizi bancari online, Amazon, Facebook, ecc.) O se sono al sicuro semplicemente chiudendo la scheda o il browser. Sono sicuro di aver sentito in alcuni programmi TV che è meglio disconnettersi ...

A quali possibili minacce mi espongo se non esco correttamente?

97
Angelo.Hannes

Questa non è una domanda banale e semplicistica. Esistono diversi aspetti che è necessario considerare e diversi meccanismi e contromisure che si applicano a diverse minacce in diversi scenari che sono interessati da diversi clienti. Esaminiamo questi uno alla volta. (Ci sarà un TL; DR alla fine ...)

  • Se stai utilizzando un computer pubblico: LOG OUT.
    Qualsiasi servizio su cui tieni un account non deve essere lasciato su un computer accessibile pubblicamente.

  • Se stai utilizzando un servizio Trivial insensibile: STAY LOGGED IN.
    Questo vale solo per gli account temporanei da buttare via, come per la radio su Internet, in cui concedere l'accesso non è altro che un fastidio.

  • Se stai utilizzando Wifi pubblico: LOG OUT.
    Poiché la rete è intrinsecamente non attendibile, esiste un grosso ovvio MINACCIA: furto di cookie di sessione. È possibile che la tua sessione sia stata dirottata, e qualcuno - o qualcun altro sulla rete o lo stesso hotspot - ha rubato il cookie della sessione. Ovviamente, se questo fosse il caso, non lo sapresti, ma potresti non essere in grado di disconnetterti (se si tratta di una rete dannosa o MITM, hanno il controllo di tutta la tua connessione - potrebbero semplicemente abbandonare il tuo richiesta di disconnessione).

    Detto questo, il furto di terze parti del solo cookie di sessione IS una minaccia valida (ad es. FireSheep ) e la disconnessione esplicita impedisce un uso illimitato. (Fondamentalmente il danno potrebbe avere stato già fatto, ma questo impedisce di continuare.)

    Ancora meglio sarebbe andare su una rete fidata, accedere e disconnettersi esplicitamente, per ogni evenienza il MITM ha bloccato il logout. Meglio ancora è cambiare la password sul sito attendibile ... Ma è meglio non accedere mai a un sito non banale e sensibile da una rete non attendibile.

  • Se stai utilizzando Applicazioni per tutto il giorno: STAY LOGGED IN.
    Per i servizi che utilizzi tutto il giorno e ai quali desideri accedere rapidamente/facilmente, ad es. Facebook, e-mail, ecc. - Se questo è il tuo computer privato (o di lavoro) su una rete fidata, è un buon compromesso lasciare il tuo browser connesso a lungo termine.

    MINACCIA: passante dannoso

    Blocca il computer ogni volta che ti allontani, anche per prendere una tazza di caffè. O chiudi a chiave il tuo ufficio, se hai una porta fisica che nessun altro può attraversare. (O avere un ufficio a casa, wheee!) Disconnettersi e riconnettersi periodicamente. Monitorare tutti i post "scritti".

    MINACCIA: Altri siti possono registrare che hai effettuato l'accesso (ad es. Per mostrarti quell'importante icona "Mi piace" di Facebook). Questo fa parte del compromesso che si applica, mentre ci sono implicazioni più ampie che non rientrano nell'ambito di questa risposta.

  • Se si utilizza Qualsiasi applicazione che utilizza l'autenticazione di base HTTP (ad es. Molti router): LOG OUT E CLOSE [~ # ~] all [~ # ~] = BROWSER WINDOWS. Qui è dove diventa interessante, e questo vale anche per la sezione successiva.

    Quando accedi a una webapp usando Basic AuthN, il browser memorizza nella cache la tua password e la invia ad ogni richiesta. Il meccanismo BasicAuth del browser non ha il concetto di sessione. Anche se ti disconnetti ripetutamente, la webapp non ha - né lato server né lato client - alcun modo di "uccidere" la sessione. L'unico modo per cancellare quelle credenziali memorizzate nella cache è interrompere il processo del browser.

    [~ ~ #] invece [~ ~ #] . La scelta del browser è importante per questo concetto di "processo del browser". Per esempio.:

    • Firefox : sempre un singolo processo, indipendentemente dal numero di schede e finestre aperte.

    • Chrome : ogni scheda è un processo separato. Tuttavia, esiste un altro processo "globale" parent. Tutti i processi di tabulazione sono processi figlio di questo (noto anche come "processo di processo" in Windows Parlance), e condividono tutti la memoria di processo attraverso il genitore. Questo vale anche se apri una nuova finestra. Quindi, mentre l'ampio uso di Chrome dei processi figlio con i genitori condivisi rende le sue schede particolarmente vivaci e robuste, il rovescio della medaglia è la condivisione dello stato del processo. In altre parole, l'unico modo per rimuovere le credenziali BasicAuth memorizzate nella cache da Chrome è chiudere tutte Chrome Windows, tutte le ultime. Chiudere la scheda da sola non aiuta .

    • [~ # ~] cioè [~ # ~] : il modello di scheda/processo è identico (o simile) a Chrome ... con un'eccezione. By default, IE apre anche tutte le schede in un figlio del processo genitore. (In realtà, questo non è accurato al 100% - alcune schede condividono un processo figlio con altre schede, ma questo non ha importanza nella realtà). Tuttavia, se aggiungi "-NoFrameMerging "alla IE riga di comando, creerà un processo genitore IE completamente nuovo. La differenza qui è che puoi ad esempio creare una nuova finestra genitore solo per accedere al tuo router e quindi chiudere solo quella finestra quando hai finito. Questo cancella la cache di BasicAuth, senza toccare altre finestre aperte IE windows. ( Nota a margine: in realtà è possibile farlo con Chrome! Tuttavia, è molto più coinvolto e richiede di creare un altro profilo del browser sul tuo computer.)

  • Se stai utilizzando Applicazioni sensibili, ad es. applicazioni bancarie - SEMPRE ESPLICITAMENTE ESEGUITI E CHIUDI [~ # ~] tutti [~ # ~] BROWSER WINDOWS. Questa parte è un po 'più complicata, ma molte delle dipendenze erano già coperte sopra.

    MINACCIA: astuto dannoso Il blocco del computer, come sopra, avrebbe senso, tuttavia non è necessario il compromesso da prima. Esci.

    Timeout della sessione: Inoltre, le app più sensibili (ad es. Bancarie) dovrebbero implementano una qualche forma di timeout di inattività automatico, quindi se esci per il pomeriggio la tua sessione morirà automaticamente ad un certo punto. Questo potrebbe non essere d'aiuto con questa minaccia, dal momento che lo spettatore dannoso potrebbe saltare sul tuo computer se esci per 4 1/2 minuti per riempire il tuo caffè.

    MINACCIA: furto di cookie di sessione

    Si spera che le app sensibili lo impediscano attivamente, ad es. HTTPS, IDS, rilevamento di geo/frode, ecc. Detto questo, ha ancora senso chiudere quella "finestra di opportunità", per ogni evenienza - difesa in profondità, e tutto il resto.

    Timeout della sessione: come in precedenza, le app più sensibili (ad es. Bancarie) dovrebbero implementano una qualche forma di timeout di inattività automatico e aiuteranno minimizzare anche questa minaccia. Comunque, anche se sai per certo che questa app implementa correttamente i timeout di inattività, c'è ancora una finestra di opportunità per l'attaccante. Detto questo, in un'app relativamente sicura questo non rappresenta una minaccia.

    MINACCIA: Falsificazione richiesta tra siti (CSRF)

    Questo è quello di cui devi preoccuparti.

    Supponi di aver effettuato l'accesso alla tua banca. Nella stessa finestra, in un'altra scheda, stai navigando in alcuni siti Web dubbi. Durante la visualizzazione di questo sito Web, potrebbe essere testando di nascosto vari siti noti, per vedere se ti è capitato di accedere a uno di essi. Se lo sei, monterà l'attacco CSRF (non tutti i siti bancari sono vulnerabili a questo, ma molti lo sono ancora). CSRF'd !

    Va bene. Ora dì che sei più intelligente di quell'altro ragazzo e non navigare su siti sospetti nello stesso momento in cui il tuo sito è aperto. Quindi, dopo aver finito sulla tua banca, chiudi attentamente la scheda. Solo allora apri una nuova scheda per navigare nel sito pericoloso. Bene, il problema è che sei ancora loggato, e lo sarà per un po '(in genere circa 30 minuti, ma potrebbe essere un minimo di 10 o fino a un'ora ...). CSRF'd !.

    (Nota che il timeout della sessione qui aiuta, accorciando la finestra di opportunità, ma c'è ancora una possibilità che ciò accada all'interno della finestra).

    Hmm. Bene, lo so, apriamo una nuova finestra del browser! Usalo per il lavoro in banca, quindi CHIUDI nuovamente la scheda e aprine di nuovo una nuova per i siti di malware con cui mi piace giocare. Spiacenti, vedere la sezione precedente sull'autenticazione di base: la scelta del browser è importante.

    A meno che tu non stia utilizzando "navigazione in incognito/navigazione privata" o "-NoFrameMerging "flag per IE, sei ancora nella stessa famiglia di processi e questa sessione ancora aperta verrà condivisa tra tutte le finestre, almeno fino a quando il server non raggiungerà il timeout di inattività. non è già stato cooptato. CSRF'd !

    Ok, ancora uno, solo uno. Ho letto questo post troppo lungo da qualche parte, su come ho sempre bisogno di disconnettermi dalle mie app sensibili - quindi faccio proprio questo, prima di comparire sui miei siti criminali. Sfortunatamente, l'applicazione "ha dimenticato" di fare un logout corretto, mi reindirizza semplicemente fuori dall'applicazione (o cancella il mio cookie, o ...) invece di invalidarlo sul server ... CSRF'd!


Quindi, TL; DR?

  • Se ti interessa il tuo account su questo sito: LOG OUT.
  • Se ti interessa il tuo account e utilizza l'autenticazione di base: SCOLLEGATI E CHIUDI TUTTE LE SCHEDE E LE FINESTRE DEL BROWSER.
  • Se non ti interessa il tuo account, non importa cosa fai, quindi smetti di chiedere :-).

Post scriptum Non ho trattato cose come cookie Flash, sessioni non http e autenticazione integrata di Windows. Quando è troppo è troppo.

89
AviD

Quando accesso a un servizio Web, viene inserito un cookie nel browser. Questo cookie ha un valore ID univoco che ti identifica mentre stai utilizzando il servizio web e, possibilmente, quando torni più tardi. Se, in qualche modo *, quell'identificatore fosse stato rubato, la persona che lo possiede potrebbe, possibilmente, utilizzare il tuo account come se fosse te.

Logout, di solito, invalida questo identificatore sia per te che per l'avversario. Nessuno di voi sarà in grado di utilizzare l'identificatore per dire al servizio web " Ciao, sono Angelo Hannes ". Ciò ha lo sfortunato effetto collaterale di forzare l'utente a inserire nuovamente nome utente e password per accedere.

"Allora, cosa dovrei fare, allora?", Chiedi. Beh, dipende. Alcuni servizi Web sensibili (banche, siti Web governativi, compagnie assicurative, ecc.) Hanno un breve periodo di sessione, ovvero invalidano l'identificatore dopo 10-15 minuti di non utilizzo del servizio. Altri servizi Web sensibili (casella di posta elettronica, che controlla praticamente quasi tutti gli altri account) non invalidano la sessione molto spesso, ma applicano restrizioni sull'indirizzo IP (se si utilizza la stessa sessione da un indirizzo IP diverso, la sessione è invalidato).

TL; DR

  • Computer pubblico, extra paranoico, pensi che la tua sessione sia stata compromessa o ti interessa davvero questo servizio? Logout.

  • Computer privato, pensi che la tua sessione sia sicura e davvero non ti interessa questo servizio? Va bene rimanere loggato.


* La tua sessione può essere rubata utilizzando problemi noti nel servizio (non utilizzando HTTPS, ad esempio) o alcune vulnerabilità zero-day come un attacco XSS appena scoperto nel servizio, una nuova vulnerabilità nel tuo browser che rivela informazioni sui cookie o alcuni malware installato sul computer che stai utilizzando che ruba le informazioni sulla sessione (beh, in tal caso avrebbe già rubato il tuo nome utente e password).

40
Adi

Proverò a fornire una risposta a questa domanda in modo inverso a quello già pubblicato sopra.

Quali sono i rischi associati alle sessioni inattive nelle applicazioni Web?

  • Furto di cookie di sessione tramite XSS (se la sessione non è legata all'IP)
  • contraffazione richiesta sito incrociato (nella sessione inattiva ma ancora autenticata).
  • Man In The Middle Attacks (utilizzando un cookie di sessione sniffato utilizzando SSLStrip o a causa della divulgazione di informazioni HTTPS miste)
  • Open Terminal (Sei partito per una pausa pranzo con Paypal aperto accanto a <inserisci qui il nome del criminale informatico casuale> e sei tornato a vedere il tuo account vuoto perché non ti sei disconnesso)

Timeout Come affermato in precedenza, alcune applicazioni critiche per la sicurezza come i siti Web bancari hanno valori di timeout bassi generalmente compresi tra i cinque ei dieci minuti. Tuttavia, queste applicazioni generalmente hanno anche token di prevenzione CSRF e IP sequenziali casuali legati alle sessioni. Pertanto, anche se il tuo cookie è compromesso, non c'è nulla che un utente malintenzionato remoto possa fare con esso se la sicurezza è stata implementata correttamente.

Altri siti Web come FaceBook non scadono le sessioni in generale per una migliore facilità di accesso o usabilità. Tuttavia supportano la notifica di accesso, IP Binding al cookie. Applicazioni come Gmail o DropBox supportano 2-step SMS Auth per migliorare ulteriormente la sicurezza e rendere inutili i furti di sessione se provengono da un nuovo PC non attendibile.

Pertanto, l'unica preoccupazione che avrei avuto è di lasciare sessioni aperte su:

  • Terminali pubblici (dove dovresti comunque utilizzare la navigazione privata. Ctrl + Maiusc + P su FF)
  • Siti web con scarsa sicurezza (dove l'utente è responsabile di preservare la segretezza dei suoi cookie dai mostri dei cookie malvagi là fuori).
11
Rohan Durve

Una delle maggiori minacce per non disconnettersi è l'utilizzo di un computer pubblico. A seconda della configurazione del browser, la chiusura del browser potrebbe non terminare una sessione. Se l'utente dimentica di disconnettersi dal suo utente del sistema operativo (o potrebbe non essere nemmeno in grado di farlo), qualcun altro può accedere alla sua webapp. Questo, ovviamente, non è un caso molto probabile. Ma le webapp sono spesso accessibili per un grande gruppo di utenti e alcuni utenti possono utilizzare computer pubblici (università, scuole, biblioteche).

4
user31950

Dal momento che una sessione ha un timeout, dopo aver usato la webapp c'è poco tempo per accedere.

Questo non è necessariamente vero. A seconda di come il sito implementa la gestione delle sessioni, potrebbero utilizzare un timeout arbitrariamente lungo e persino utilizzare sessioni che sopravvivono al riavvio del browser/sistema operativo.

In definitiva, la disconnessione esplicita o meno dipende dall'app Web. I siti bancari in genere implementano un timeout molto breve, i siti di social network in genere implementano accessi essenzialmente permanenti soprattutto se sono anche provider di identità (OpenID, ecc.).

Di solito, rubare un cookie di sessione non è facile, ma è possibile e la disconnessione esplicita lo impedisce, in genere è necessario disconnettersi esplicitamente per siti di alto valore.

4
Lie Ryan

Non dare per scontato che un servizio abbia un timeout. Anche se ha un timeout, un utente malintenzionato può semplicemente raccogliere i cookie e utilizzarli con un semplice script che continua a eseguire il ping del servizio, l'invio dei cookie e l'aggiornamento del timestamp "ultimo accesso". Esistono diversi modi per proteggersi dai proprietari di siti Web, ma non fidarsi dei proprietari di siti Web. Rubare un cookie non è così difficile come sembra (una ricerca su YouTube potrebbe mostrarti esattamente quanto sia facile) e la tua migliore protezione per questo caso è davvero il logout.

3
jpkrohling

Se non ti disconnetti, il cookie di accesso rimarrà valido per un determinato periodo (a seconda dell'implementazione), poiché il server (su cui è in esecuzione l'applicazione Web) non è a conoscenza del fatto che hai chiuso il browser. Se qualcuno ha rubato il tuo cookie, può usarlo per accedere all'applicazione e persino estenderne la validità, poiché la maggior parte delle implementazioni ha una scadenza variabile.

1
Kees de Wit

Dal punto di vista della sicurezza, a mio avviso, la risposta è semplice. Al termine della disconnessione dal sito. E una volta terminata la navigazione, svuota la cache ed elimina la cronologia, ecc. Puoi persino impostare il browser per cancellare tutto quando lo chiudi. Lascia il minor numero di tracce possibile di ciò che hai fatto.

E per favore non fare clic su alcun popup o link divertente nelle e-mail. Fai attenzione ai reindirizzamenti dal sito in cui ritieni di essere su un altro sito.

0
AquaAlex