Domanda:
Dobbiamo disconnetterci dalle webapp?
Angelo.Hannes
2013-10-14 12:03:12 UTC
view on stackexchange narkive permalink

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 qualche programma televisivo che è meglio disconnettersi ...

A quali possibili minacce mi espongo se non mi disconnetto correttamente?

Considera l'idea di chiudere una scheda più o meno come non chiudere una scheda.
@domen questo non è SEMPRE vero. Vedi ad es. la mia risposta.
In Lettonia l'internet banking di SwedBank agisce anche sull'indirizzo IP. Immagino che lo facciano anche altre banche. Esempio di vita reale: ho impostato due connessioni Internet a casa (bilanciamento del carico basato su pacchetti) e non posso usare affatto l'internet banking, perché dopo 2 o 3 clic mi disconnetto. Mi sono autenticato con un IP e poi ho fatto un'altra richiesta con il secondo IP. In questo caso il furto dei cookie non funziona.
non importa se usi un'applicazione Rails, perché "[Il logout è interrotto di default nelle applicazioni Web Ruby on Rails] (http://maverickblogging.com/logout-is-broken-by-default-ruby-on-rails -web-applications /) "... SCNR
@thatguyfromoverthere grazie per la scoperta, quella mi mancava! Nota che questo tipo di bug è abbastanza comune nelle applicazioni personalizzate, come ho detto in un commento qui sotto, non è solo Rails.
@AviD Ho letto la tua risposta. Cosa intendi esattamente?
@domen Ci sono aspetti che vengono influenzati dalla chiusura della scheda. Per esempio. per l'autenticazione di base, se è stato aperto con -NoFrameMerging o navigazione privata.
Come nota a margine: è interessante verificare se la tua applicazione critica forza una nuova autenticazione, idealmente con un mezzo diverso (= se accedi con login / password, ri-autentica / conferma con un SMS) prima di eseguire un operazione critica (come un bonifico bancario per una banca). In genere in un ambiente bancario è una cosa molto brutta che qualcuno riesca a guardare il tuo conto. È catastrofico se qualcuno riesce a emettere una transazione (trasferimento)
So già che molte risposte, ma c'è un hacker atk, che ruba i tuoi cookie e se non ti disconnetti possono ancora navigare come te
@jcho360 questo è stato menzionato in diverse risposte, in molti modi diversi. Ci sono diversi aspetti in questo, non è così semplice e diretto.
Nota che questa domanda è stata presentata su [LifeHacker] (http://lifehacker.com/do-i-really-need-to-log-out-of-webapps-1482782887), a quanto pare questo è un problema comune ...
Otto risposte:
#1
+89
AviD
2013-10-14 22:11:07 UTC
view on stackexchange narkive permalink

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.

Roba buona! una cosa da notare è che nella tua sessione mitigazioni del furto di cookie, andare su un computer attendibile ed eseguire il log-in / out presuppone che l'app. consente solo una singola sessione valida per utente e che la creazione della sessione invalida quella precedente. Sfortunatamente non è il caso in molte app (l'accesso simultaneo consentito è la maggior parte della mia esperienza).
@RoryMcCune è vero! In realtà stavo pensando di spostare un laptop da una rete wifi aperta a una rete affidabile, dove la sessione sarebbe rimasta la stessa (in realtà, non necessariamente ...). Hai ragione sui computer non affidabili, però.
Mi sono anche reso conto che non ho nemmeno menzionato come a volte il logout non funzioni neanche ... o non uccidendolo dal lato server, cancellando semplicemente il cookie del client, o altri bug stupidi come quello. La mia ipotesi implicita in tutto questo è che * logout funzionerà *, se lo usi - questa ipotesi non è sempre vera.
Per svelare un punto importante della risposta di AviD: Se * davvero * ti interessa l'account: uccidi tutti i processi del browser, inclusi gli spawn dei plugin (PDF incorporato, lettore musicale e popup di applet); quindi accedi solo al sito web dell'account; quindi uccidere nuovamente tutto prima di riavviare le normali abitudini di navigazione. In sostanza, non garantire parallelismo durante l'accesso agli account critici poiché i browser sono "sistemi operativi Web" che tendono verso un maggiore parallelismo e condivisione, non meno.
Per inciso, relativo al 2 ° TL di AviD; punto elenco DR: se si utilizza il plug-in WebDeveloper per Firefox, Varie | Cancella dati privati ​​| Cancella autenticazione HTTP. Questo ti eviterà di dover chiudere tutte le schede e le finestre.
Quando la mia sessione non è sicura, dopo aver chiuso la scheda / il browser, allora non è sicura mentre lo sto usando, vero? E quindi nemmeno la webapp da sola?
Va notato che Chrome e alcuni altri browser hanno una "finestra di navigazione in incognito" con credenziali separate e cache dei cookie. Se ti dispiace aprire una finestra di navigazione in incognito per accedere a tale sito, non devi chiudere altre finestre in seguito.
Non menzionata (almeno esplicitamente) è la funzione "ricordami" utilizzata da molti siti web. Quindi, anche dopo aver chiuso il browser e spento la macchina, alla "tua" prossima visita al sito verrai automaticamente connesso. Di solito, la disconnessione interromperà anche la funzione "ricordami", quindi questo è un altro punto in più per la registrazione da siti sensibili.
@JanHudec Grazie, mi stavo chiedendo. Normalmente navigo con Chrome con molte schede aperte e utilizzo Safari (su OSX) per fare le mie cose sensibili. Una finestra di navigazione in incognito sarebbe una buona alternativa.
@LateralFractal Molto vero, e per quanto riguarda i plugin che ho menzionato nella nota a piè di pagina, cose come Flash (che sembra essere il più comune, non solo in quanto esistente, ma con difetti rilevanti). Grazie per gli altri esempi di plugin.
@DarrenCook grazie per questo! Continuo a cercare quell'opzione, continuo a dimenticare che hai detto che è solo con il plugin WebDeveloper ... ma aiuterebbe il piccolo segmento che lo usa :-)
@Angelo.Hannes "sicuro" è un termine relativo. Se hai aperto la sessione in un processo condiviso (cioè non utilizzando la navigazione privata o NoFrameMerging di IE), allora - non è necessariamente * non sicuro *, ma ci sono alcuni rischi. Per esempio. se esiste un difetto CSRF, è vulnerabile ad altre schede che attaccano allo stesso tempo, ecc. Se un utente malintenzionato ha rubato il tuo cookie di sessione, sei a rischio irrilevante delle schede o meno, ma allora è solo una questione di chiudere la finestra di attacco (quindi, sì, non sei più sicuro dopo non esserti disconnesso rispetto a quando sei loggato). Il problema è che potrebbe NON esserci un timeout ...
@JanHudec corretto, l'ho menzionato solo di sfuggita.
Punto eccellente di @CarlosCampderr! Presumo che se ti stai disconnettendo, non sei interessato a "ricordami", ma questa ipotesi potrebbe essere sbagliata. Inoltre, molto spesso la funzione "ricordami" è molto insicura.
* MINACCIA: astante dannoso * - la maggior parte degli astanti maliziosi che tentano di "dirottare" il mio computer perderebbero almeno un po 'di tempo a causa della confusione di [Dvorak] (http://en.wikipedia.org/wiki/Dvorak_simplified_keyboard) ;-)
@gerrit hehe, sì, ma questa è sicurezza per oscurità - e probabilmente ti farebbe guadagnare solo pochi minuti. Alla fine strapperanno la tastiera dal cavo, lanceranno i pezzi maciullati attraverso la stanza e collegheranno la loro tastiera.
@AviD Vero, non fermerà un attaccante concentrato e dedicato e non lo considero una protezione seria. Ma quando sto letteralmente prendendo solo tè o caffè, un minuto può essere appena sufficiente per fare la differenza.
Questo consiglio si applica ancora alla [pressione del pulsante Indietro / cronologia] (http://security.stackexchange.com/q/8404/396) per eseguire nuovamente l'autenticazione a un cookie SAML / federato? Sarebbe interessante vedere gli scenari che influenzano le varie direttive di caching ... probabilmente è documentato nel (vecchio?) Manuale sulla sicurezza del browser di Google
#2
+40
Adi
2013-10-14 12:59:36 UTC
view on stackexchange narkive permalink

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).

Quindi le minacce sono le stesse, mentre sono loggato e disconnettersi accorcia solo il lasso di tempo?
Vorrei aggiungere che XSS può essere utilizzato per eseguire richieste contraffatte, nel qual caso il timeout sul cookie è irrilevante.
Ciò significa che, se il mio laptop viene rubato, le credenziali dovrebbero essere automaticamente invalidate, perché l'IP cambierà?
@ ŁukaszL. _Alcuni_ servizi hanno timeout, altri no. _Alcuni_ servizi hanno restrizioni IP, altri no.
Se ti interessa davvero il servizio (o compromettere il servizio potrebbe portare ad attacchi che compromettono i servizi che ti interessano, ad esempio, usa il tuo account e-mail per accedere al tuo conto bancario tramite una reimpostazione della password), non dovresti ** mai ** utilizzare il servizio su un computer pubblico non attendibile o su un wifi pubblico (beh, tecnicamente, il wifi pubblico va bene se è https per l'intera connessione e né la tua macchina né la CA sono stati compromessi).
@drjimbob Se i computer USB come [Cotton Candy] (http://www.fxitech.com/cotton-candy/what-is-it/) non sono vaporware, allora puoi tranquillamente usare un computer host non affidabile in quel modo.
@LateralFractal - [Hardware keylogger] (http://en.wikipedia.org/wiki/Hardware_keylogger). (Certo, con l'autenticazione a 2 fattori potresti essere potenzialmente al sicuro in questa situazione - se le tue password memorizzate sono completamente inutili nelle mani di un avversario - ma in realtà anche in quel caso, perché non accedere dal tuo dispositivo secondo fattore).
@drjimbob Ci sono gradi di fiducia, quindi se anche l'hardware non è affidabile allora sei ovviamente limitato a qualsiasi personal computer che puoi portare con te. Tuttavia i laptop sono piuttosto grandi ei telefoni cellulari sono radiofari, quindi un computer stick delle dimensioni di un KitKat è allettante. Lo scopo dei computer headless è fornire una gamma più ampia di contenuti protetti rispetto al seed a 256 bit su un dongle OTP, prendendo in prestito le risorse dell'host. Anche se non sono un amante di quello che probabilmente è vaporware, a seconda di come è collegato, le uniche risorse host dovrebbero essere un monitor HDCP-HDMI e il suo alimentatore.
In altre parole, * il perfetto è nemico del bene. *
@LateralFractal - Non usa una tastiera che potrebbe non essere la tua? Da quando siamo entrati nell'era dei dispositivi mobili tascabili, non ricordo di aver mai avuto bisogno di utilizzare computer pubblici / non attendibili per fare cose come controllare la mia posta elettronica (o peggio conto bancario) o accedere a un server. E non sono nemmeno particolarmente paranoico.
@drjimbob In pratica, la soluzione migliore sarebbe un telefono con la capacità di cooptare altre risorse a seconda dei casi (monitor più grande, tastiera, Ethernet fissa, ecc.). Allo stato attuale i cellulari consumer ([post-Blackberry] (http://goo.gl/ybm7Fl)) sono * molto * meno sicuri di qualsiasi desktop, compresi quelli headless. Ma temo che siamo andati fuori tema. Potremmo usare Chat per ulteriori elaborazioni.
#3
+11
Rohan Durve
2013-10-14 18:03:47 UTC
view on stackexchange narkive permalink

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).
Un vettore di attacco interessante sarebbe vedere se un uomo nel mezzo dello sniffer sulla tua LAN NAT potrebbe interrompere la crittografia di una sessione, ottenere una coppia cookie-token, falsificare una richiesta post dannosa, crittografarla con il cookie-token incapsulato e il modulo dati e inviarli tramite il tuo IP pubblico.
#4
+4
user31950
2013-10-14 12:22:41 UTC
view on stackexchange narkive permalink

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).

Anche se avevo in mente solo i miei dispositivi privati, è un buon punto menzionare i dispositivi accessibili al pubblico. Lo stesso vale per i dispositivi incustoditi o smarriti / rubati.
#5
+4
Lie Ryan
2013-10-14 12:23:54 UTC
view on stackexchange narkive permalink

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.

Potresti entrare più in dettaglio, come rubare un cookie di sessione? È generalmente possibile o solo a causa di exploit sconosciuti o zero-day? Sarebbe utile stimare la minaccia.
dai un'occhiata all'estensione per Firefox "Firesheep" per scoprire quanto sia facile rubare i cookie di sessione.
#6
+3
jpkrohling
2013-10-14 17:12:24 UTC
view on stackexchange narkive permalink

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.

#7
+1
Kees de Wit
2013-10-14 23:24:20 UTC
view on stackexchange narkive permalink

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.

#8
  0
AquaAlex
2013-10-15 11:55:43 UTC
view on stackexchange narkive permalink

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.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...