Trasferimento di informazioni tra browser e schede

Difficile rispondere perché possiamo avere molti orizzonti qui.

Risposta breve:

Userò la tua banca come esempio.

Diciamo che apri una nuova scheda e inserisci su your-bank.com.

Se la tua banca non ha esplicitamente sviluppato alcun codice per comunicare con altre schede, nessun'altra scheda potrebbe dire che stai visitando la tua banca e cosa stai facendo lì. *

TRANNE se una scheda malevola utilizza un exploit del browser (0 giorni), che è molto costoso, raro ed estremamente illegale.

• Non sto pensando di aver cliccato su your-bank.com attraverso altri siti, e sto considerando che non hai alcuna estensione / plugin o malware per il browser nel tuo computer.

(...) please describe what safeguards are in place within the browser in addition to sandboxing

Polizza di origine (SOP):

"In computing, the same-origin policy is an important concept in the web application security model. The policy permits scripts running on pages originating from the same site – a combination of scheme, hostname, and port number1 – to access each other's DOM with no specific restrictions, but prevents access to DOM on different sites.1 The same-origin policy also applies to XMLHttpRequests unless the server provides an Access-Control-Allow-Origin (CORS) header. Notably, WebSockets are not subject to the same-origin policy.

This mechanism bears a particular significance for modern web applications that extensively depend on HTTP cookies to maintain authenticated user sessions, as servers act based on the HTTP cookie information to reveal sensitive information or take state-changing actions. A strict separation between content provided by unrelated sites must be maintained on the client side to prevent the loss of data confidentiality or integrity."

From Wikipedia (http://en.wikipedia.org/wiki/Same-origin_policy).

Modifica:

Considerazioni su questo post (userò di nuovo la tua banca come esempio):

Il metodo document.domain

Qui possiamo supporre che subdomain.attacker.com possa parlare con subdomain.attacker.com AND attacker.com. Ma è impossibile sottodominio.attacker.com parlare con your-bank.com o anche con subdomain.your-bank.com.

Perché? attacker.com non può impostare il suo document.dominio su your-bank.com.

Ilmetododicondivisionedellerisorseincrociate

Quilatuabancadeveautorizzareesplicitamentelacondivisionedellerisorsetraoriginiconattacker.com,perchénonèconsentitaperimpostazionepredefinita.

Impostazionidiundominiovulnerabile:

Access-Control-Allow-Origin:*Access-Control-Allow-Methods:GET,POST,DELETE,PUT

Ilmetodowindow.postMessage(oJSONP,ecc.)

AncoraunavoltalatuabancahabisognodicomunicazioniesplicitetramitejavascriptpostMessage.

Lemieconclusioni:

Lapoliticadellastessaorigineè,algiornod'oggi,moltoaffidabile,macomequalsiasicosa,nonèimpeccabile.

Tuttavia,setroviqualchedifettonell'implementazionedellapolicydiorigineidenticadiChromeoFirefox(comeU-XSS,ecc.),riceveraiunabellaricompensa.

Quindinonèfaciletrovareunbug.

ProgrammidibugbugdiMozillaeChrome:

link
link

Articolo su alcune vecchie debolezze della politica di origine:

link

Is this the only in-browser mechanism/defense that is preventing tab/browser crosstalk?

Sì, la politica della Stessa origine è l'unico meccanismo per prevenire i dialoghi di origine incrociata.

Modifica 2:

Are the exploits you detailed above persistant across browser closings, or do they only affect simultaneous connections?

Sia! Possiamo avere exploit persistenti e non persistenti.

Daniel Divricean ha riportato questo exploit non persistente tre anni fa. Un utente malintenzionato può leggere le informazioni di altri siti, ad esempio il tuo conto in banca, ma solo se hai già effettuato l'accesso alla tua banca. In questo caso, la chiusura del sito dannoso interromperà l'attacco.

Ho segnalato questo exploit persistente a Google un anno fa. Un utente malintenzionato potrebbe utilizzarlo per installare un'estensione malevola sul browser della vittima, senza l'interazione e la conoscenza dell'utente. In questo caso, la chiusura del sito dannoso NON arresta l'attacco.

So is logging into the bank website -> logging out -> closing browser -> opening exploit site -> closing browser -> logging into bank... now safe?

È più sicuro, non completamente sicuro.

Oltre alla risposta eccellente di Lucas NN , c'è anche la minaccia di Controprodotto di richiesta sito Croce .

CSRF non richiede che ci sia una scheda corrente aperta nel browser, solo una sessione valida. Quindi, se hai effettuato l'accesso a Facebook e Facebook, sembra che contenga una vulnerabilità CSRF, e ti capita di visitare un sito malvagio che sfrutta questa vulnerabilità, il tuo account Facebook potrebbe essere compromesso. Questo è un buon caso per aprire siti sensibili in un altro browser o una scheda di navigazione in incognito che non condivide meccanismi di autenticazione come i cookie di autenticazione con le normali schede del browser. Anche così, l'aspettativa è che un sito web bancario sia sicuro contro tali attacchi.