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

• Se utilizzi un computer pubblico: ESCI.
  Qualsiasi servizio su cui mantieni un account non deve essere lasciato connesso su una macchina accessibile pubblicamente.

• Se stai utilizzando un servizio banale non sensibile: RIMANI CONNESSO.
  Ciò si applica solo agli account temporanei usa e getta, come per quanto riguarda la radio su Internet, dove dare via l'accesso non è altro che un fastidio.

• Se utilizzi Wifi pubblico: ESCI.
  Poiché la rete è intrinsecamente non affidabile, c'è un grande ovvio MINACCIA: furto di cookie di sessione. È possibile che la tua sessione sia stata dirottata e qualcuno, qualcun altro sulla rete o l'hotspot stesso, abbia rubato il cookie di sessione. Ovviamente, se fosse così, non lo sapresti, ma potresti non essere in grado di disconnetterti davvero (se si tratta di una rete dannosa o MITM, hanno il controllo dell'intera connessione - potrebbero semplicemente interrompere il tuo richiesta di logout).

  Detto questo, il furto di terze parti del solo cookie di sessione È una minaccia valida (ad esempio FireSheep) e la disconnessione esplicita ne impedisce l'uso illimitato. (Fondamentalmente il danno potrebbe essere già stato fatto, ma questo impedisce che continui.)

  Sarebbe ancora meglio andare a una rete affidabile, accedere e disconnettersi esplicitamente, per ogni evenienza il MITM ha bloccato la tua disconnessione. Ancora meglio è cambiare la password sul sito attendibile ... Ma è meglio non accedere mai a un sito sensibile non banale da una rete non attendibile.

• Se utilizzi applicazioni che durano tutto il giorno: RIMANI CONNESSO.
  Per i servizi che utilizzi tutto il giorno e desideri un accesso rapido / facile, ad es. Facebook, e-mail, ecc. - SE questo è il tuo computer privato (o di lavoro) su una rete affidabile, è un buon compromesso lasciare il tuo browser connesso a lungo termine.

  MINACCIA : Spettatore malvagio

  Blocca il computer ogni volta che ti allontani, anche per prendere una tazza di caffè. Oppure chiudi a chiave il tuo ufficio, se hai una porta fisica che nessun altro può varcare. (O avere un ufficio a casa, wheee!) Esci periodicamente e torna indietro. Monitora tutti i post "che" fai.

  MINACCIA: altri siti possono registrarsi 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 sono fuori portata per questa risposta.

• Se stai utilizzando Qualsiasi applicazione che utilizza l'autenticazione di base HTTP (ad esempio molti router): ESCI E CHIUDI TUTTE LE FINESTRE DEL BROWSER. Qui è dove diventa interessante, e questo vale anche per la sezione successiva.

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

  TUTTAVIA . La scelta del browser è importante per questo concetto di "processo del browser". Ad esempio:

  • Firefox : sempre un unico processo, indipendentemente dal numero di schede e finestre che apri.

  • Chrome : ogni scheda è un processo separato. Tuttavia, esiste un altro processo genitore "globale". Tutti i processi tab sono processi figli di questo (noto anche come "processo di lavoro" nel gergo di Windows), e condividono tutti la memoria del processo tramite il genitore . Questo vale anche se apri una nuova finestra. Quindi, mentre l'ampio utilizzo da parte di Chrome di processi figlio con genitore condiviso rende le sue schede particolarmente vivaci e robuste, lo svantaggio è la condivisione dello stato del processo. In altre parole, l'unico modo per rimuovere le credenziali BasicAuth memorizzate nella cache da Chrome è chiudere tutte le finestre di Chrome, tutte le ultime. Chiudere la scheda da solo non aiuterà.

  • IE : il modello di scheda / processo è identico (o simile) a Chrome ... con un'eccezione. Per impostazione predefinita , 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 in realtà non importa). Tuttavia, se aggiungi " -NoFrameMerging " alla riga di comando di IE, verrà creato un processo principale di IE completamente nuovo. La differenza qui è che puoi ad es. crea una nuova finestra genitore solo per accedere al tuo router, quindi chiudi solo quella finestra quando hai finito. Questo cancella la cache BasicAuth, senza toccare altre finestre di IE aperte. (Nota a margine: in realtà è possibile farlo anche con Chrome! È molto più complicato, però, e richiede la creazione di un altro profilo del browser sul tuo computer.)

• Se utilizzi applicazioni sensibili, ad es app bancarie - ESCI SEMPRE ESPLICITAMENTE E CHIUDI TUTTE LE FINESTRE DEL BROWSER. Questa parte è un po 'più complicata, ma molte delle dipendenze sono già state trattate sopra.

  MINACCIA: spettatore dannoso Bloccare il tuo computer, come sopra, avrebbe senso, tuttavia non è necessario il compromesso di prima. Esci.

  Timeout della sessione: inoltre, le app più sensibili (ad esempio bancarie) dovrebbero implementare una qualche forma di timeout di inattività automatico, quindi se esci per il pomeriggio la tua sessione morirà automaticamente a un certo punto. Questo potrebbe non aiutare con questa minaccia, dal momento che lo spettatore malizioso potrebbe semplicemente saltare sul tuo computer se esci per 4 minuti e mezzo per riempire il tuo caffè.

  MINACCIA: furto di cookie di sessione

  Si spera che le app sensibili lo stiano attivamente impedendo, ad es. HTTPS, IDS, rilevamento geografico / frodi e così via. Detto questo, ha comunque senso chiudere quella "finestra di opportunità", per ogni evenienza: difesa in profondità e tutto il resto.

  Timeout sessione: come prima, le app più sensibili (ad esempio bancarie) dovrebbero implementare una qualche forma di timeout di inattività automatico e aiuteranno a ridurre al minimo anche questa minaccia. Tuttavia , 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 questa non è una grande minaccia.

  MINACCIA: Cross Site Request Forgery (CSRF)

  Questo è quello di cui devi preoccuparti.

  Supponiamo che tu abbia effettuato l'accesso alla tua banca. Nella stessa finestra, in una scheda diversa, stai navigando in un sito Web dubbio. Durante la visualizzazione di questo sito Web, potrebbe essere necessario testare di nascosto vari siti bancari ben noti, per vedere se ti è capitato di accedere a uno di essi. Se lo sei, attiverà l'attacco CSRF (non tutti i siti bancari sono vulnerabili a questo, ma molti lo sono ancora). CSRF!

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

  (Notare che il timeout della sessione qui aiuta, abbreviando 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, consulta la sezione precedente sull'autenticazione di base: la scelta del browser è importante.

  A meno che non utilizzi la "navigazione in incognito / privata" o il flag " -NoFrameMerging " per IE, sei ancora nella stessa famiglia di processi e questa sessione ancora aperta verrà condivisa tra tutte le tue finestre, almeno fino a quando il server non raggiunge il timeout di inattività. Supponendo che non sia già stato cooptato. CSRF!

  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 entrare nei miei siti criminali. Sfortunatamente, l'applicazione "si è" dimenticata "di eseguire un logout corretto, mi reindirizza semplicemente fuori dall'applicazione (o cancella il mio cookie, o ...) invece di invalidarlo sul server ... CSRF'd!

Allora, TL; DR?

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

_{P.S. Non ho trattato cose come i cookie Flash, le sessioni non http e l'autenticazione integrata di Windows. Quando è troppo è troppo.}

Quando accedi a un servizio web, un cookie viene installato nel tuo browser. Questo cookie ha un valore ID univoco che ti identifica mentre utilizzi il servizio web e, possibilmente, quando torni più tardi. Se, in qualche modo *, quell'identificatore è stato rubato, la persona che lo possiede potrebbe, possibilmente, utilizzare il tuo account come se fossi tu.

La disconnessione , di solito, invalida questo identificatore per sia tu che l'avversario. Nessuno di voi potrà utilizzare l'identificatore per dire al servizio web " Ciao, sono Angelo Hannes ". Questo ha lo sfortunato effetto collaterale di costringere te a inserire nuovamente il tuo nome utente e la tua password per accedere.

"Allora, cosa dovrei fare, allora?", Chiedi. Beh, dipende. Alcuni servizi web sensibili (banche, siti web governativi, compagnie assicurative, ecc.) Hanno un tempo di sessione breve, ovvero invalidano l'identificativo dopo 10-15 minuti di non utilizzo del servizio. Altri servizi web sensibili (la posta in arrivo, che fondamentalmente controlla quasi tutti gli altri account) non invalidano la sessione così spesso, ma applicano restrizioni sull'indirizzo IP (se usi 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 collegati .

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

Cercherò di fornire una risposta a questa domanda in modo inverso a quella già pubblicata 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)
• Cross Site Request Forgery (inattivo ma sessione ancora autenticata).
• Man In The Middle Attacks (utilizzando un cookie di sessione sniffato utilizzando SSLStrip oa causa di divulgazioni di informazioni HTTPS miste)
• Apri terminale (Sei partito per una pausa pranzo con PayPal aperto accanto ad < inserisci qui il nome del criminale informatico casuale> e sei tornato per 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 da cinque a dieci minuti. Tuttavia, queste applicazioni generalmente hanno anche token di prevenzione CSRF in sequenza casuale e IP legati alle sessioni. Pertanto, anche se il tuo cookie è compromesso, non c'è nulla che un utente malintenzionato remoto possa farci se la sicurezza è stata implementata correttamente.

Altri siti web come FaceBook non interrompono generalmente le sessioni per una migliore facilità di accesso o usabilità . Tuttavia supportano la notifica di accesso, l'associazione IP al cookie. Applicazioni come Gmail o DropBox supportano l'autenticazione tramite SMS in due passaggi per migliorare ulteriormente la sicurezza e rendere inutile il furto di sessioni se proviene da un nuovo PC non affidabile.

Pertanto, l'unica preoccupazione che avrei è lasciando le 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 cookie malvagi là fuori).

Una delle maggiori minacce per la mancata disconnessione è l'utilizzo di un computer pubblico. A seconda della configurazione del browser, la semplice chiusura del browser potrebbe non terminare una sessione. Se l'utente dimentica di disconnettere il 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 a un grande gruppo di utenti e alcuni utenti possono utilizzare computer pubblici (università, scuole, biblioteche).

Dal momento che una sessione ha un timeout, è solo un breve periodo di tempo in cui effettuo l'accesso, dopo aver utilizzato la webapp.

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

In definitiva, se è necessario disconnettersi esplicitamente o meno dipende da cosa è l'app Web . I siti della banca generalmente implementano un timeout molto breve, i siti di social network di solito implementano un accesso essenzialmente permanente, soprattutto se sono anche provider di identità (OpenID, ecc.).

Rubare un cookie di sessione di solito non è facile, ma è possibile e il logout esplicito lo impedisce, in genere dovresti disconnetterti esplicitamente per i siti di alto valore.

Non dare per scontato che un servizio abbia un timeout. Anche se ha un timeout, un utente malintenzionato potrebbe semplicemente raccogliere il tuo cookie e usarlo con un semplice script che continua a eseguire il ping del servizio, inviare il tuo cookie, aggiornare il timestamp "ultimo accesso". Esistono diversi modi in cui i proprietari di siti Web possono proteggersi da questo, ma non fidarti 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 è effettivamente disconnettersi.

Se non ti disconnetti, il cookie di accesso rimarrà valido per un determinato periodo (a seconda dell'implementazione), perché il server (su cui gira l'applicazione web) non sa che hai chiuso il browser. Se qualcuno ha rubato il tuo cookie, può utilizzarlo per accedere all'applicazione e persino estenderne la validità, perché la maggior parte delle implementazioni ha una scadenza scorrevole.

Dal punto di vista della sicurezza, a mio parere, la risposta è semplice. Quando hai finito di uscire dal sito. E quando hai finito con la tua navigazione svuota la cache ed elimina la cronologia, ecc. Puoi anche impostare il tuo browser in modo da cancellare tutto quando chiudi il browser. Lascia il minor numero possibile di tracce di ciò che hai fatto.

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