In che modo HTTPS Everywhere perde la mia sessione di Twitter da una finestra di navigazione in incognito?

Naviga le tue risposte
5

Gestisco un paio di account Twitter per aziende / siti web che sono separati dal mio account personale. Per semplicità, preferisco accedere da una finestra di navigazione in incognito in modo che non sia necessario disconnettermi dal mio account Twitter (personale) principale.

Sono rimasto scioccato quando di recente ho eseguito l'accesso a uno degli account secondari in una finestra di navigazione in incognito, chiuso la finestra e successivamente ho effettuato l'accesso a quell'account secondario quando si visita Twitter nella finestra principale non in incognito.

Ho eseguito alcuni test e ho riscontrato che l'accesso automatico si verifica indipendentemente dal fatto che sia attualmente connesso a Twitter o meno nella sessione principale del browser, ogni volta che accedo tramite la finestra di navigazione in incognito. Se lascio la finestra di navigazione in incognito aperta e accedi a un altro account, anche la sessione del browser principale passa a quell'account Twitter.

Dopo alcuni spunti aggiuntivi, ho deciso di disabilitare le estensioni che avevo abilitato in modalità in incognito, per determinare se fosse correlato. Il problema è scomparso con tutte le estensioni disattivate. Le uniche 2 estensioni che avevo dato il permesso di operare in modalità in incognito erano Adblock e HTTPS Everywhere. Ho attivato ciascuno di essi singolarmente e il problema si verifica solo quando HTTPS Everywhere è abilitato. Ho inoltre stabilito che il problema appare su Twitter. L'accesso a un altro account Facebook, Gmail o Reddit in modalità di navigazione in incognito (con HTTPS Ovunque abilitato) non ha influito sullo stato di accesso nella sessione del browser principale.

Ovviamente, questo è un problema di sicurezza, specialmente per un'estensione orientata alla privacy che perde i dati di sessione. Nello specifico, mi chiedo:

  • In che modo HTTPS Everywhere aiuta Twitter a uscire dalla modalità di navigazione in incognito "sandbox"?
  • Perché questo succede con Twitter ma nessun altro sito?
  • In che modo un sito Web dannoso può sfruttare questo bug per rubare o alterare le credenziali dell'utente?

Nota: questo non accade in Firefox utilizzando la modalità di navigazione privata con HTTPS Ovunque abilitato.

    
posta nhinkle 11.02.2014 - 06:44
fonte

2 risposte

5

Sono il manutentore di HTTPS Everywhere e ho appena unito una richiesta pull che risolve questo problema. Dovrebbe essere nella prossima versione (fuori tra 1-2 settimane). Per riferimento futuro, l'invio di questi a Github significa che verranno risolti prima :). ( link )

    
risposta data 05.04.2014 - 08:39
fonte
4

Ho trovato un rapporto bug di HTTPs Everywhere che spiega perché questo accade:

This appears to be an Chrome API bug. We're getting the onCookieChanged event, and the cookie we get in that event has a storeId of 0 regardless of where it comes from (Incognito or not). We then turn right around and set the secure flag on the cookie and issue a cookies.set(cookie). Since the storeId is still the default store, the cookie leaks to normal mode.

Non è chiaro il motivo per cui sembra accadere ad alcuni siti e non ad altri, ma altre fonti sul web hanno confermato che il problema appare in modo affidabile con Twitter. È possibile che HTTPs Everywhere modifichi il cookie solo se il flag di sicurezza non è già impostato e che altri importanti siti Web stanno già impostando il flag di protezione sui loro cookie, mentre Twitter non lo è. Ulteriore ricerca su questo sarebbe gradita.

Ho ripresentato il bug report al bug tracker GitHub più usato del progetto , e ho incluso un raccomandazione per rilevare la modalità di navigazione in incognito e non riscrivere i cookie quando si utilizza la modalità di navigazione in incognito.

    
risposta data 11.02.2014 - 06:51
fonte

Leggi altre domande sui tag

Il phpseclib è un'alternativa sicura e affidabile a OpenSSL? Che cosa può e non può fare un DNS dannoso?