Informazioni su SOP in più schede

I'm not able to understand how can the malicious domain access facebook account from a different tab and how does SOP protect against this?

Le schede non sono entità isolanti. Cioè, i cookie sono condivisi tra ogni finestra aperta da un browser, comprese tutte le schede su quelle finestre. L'unica eccezione a questa sono le finestre private / in incognito. Pertanto, se una scheda aperta su evil.com effettua una richiesta AJAX su facebook.com , i tuoi cookie auth da facebook.com verranno inviati insieme alla richiesta. Lo stesso criterio di origine impedisce evil.com da lettura la risposta da facebook.com in quanto i domini non corrispondono.

The malicious domain is free to send a GET/POST request to facebook.com, and the browser will attach a cookie for facebook if available. But then wouldn't the problem be due to facebook's server side protection (CSRF scenario)? How does SOP help in this case?

La protezione CSRF dovrebbe solo prevenire i metodi non sicuri - azioni con effetti collaterali. Cioè:

the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Quindi, se il sito è stato implementato rispetto a questa convenzione, la protezione CSRF dovrebbe essere attiva solo per i POST (anche tecnicamente PUT e DELETE, ma questi sono usati raramente).

Come detto, il SOP non interrompe le richieste, ma solo le risposte da leggere. Anche con il SOP, evil.com potrebbe effettuare una richiesta POST alla pagina "Elimina account" di facebook.com , e se l'utente ha effettuato l'accesso a Facebook, i cookie verranno inviati.

Tuttavia, se Facebook ha implementato la protezione CSRF utilizzando i token nella pagina Elimina account, un token CSRF dovrà essere inviato con questo POST. evil.com può effettuare una richiesta GET a facebook.com alla pagina contenente il token CSRF. Tuttavia, l'SOP impedisce che la risposta sia letta . Il SOP protegge i token CSRF di Facebook e impedisce che gli attacchi CSRF si verifichino quando sono protetti da token.

Il dominio dannoso non può accedere all'account facebook da una scheda diversa perché SOP impedisce agli script, che il browser sa provenire da evil.com , dall'accesso a proprietà e metodi di script provenienti da victim.com.

Il problema è che poiché HTTP è senza stato, se uno script di evil.com in esecuzione sul tuo browser dovesse emettere una richiesta a un servizio su victim.com, il servizio vedrebbe una richiesta proveniente dal tuo browser (non "una scheda sul tuo browser "), e forse lo onorerei. Per impedire ciò, il sito determina che rispetterà la richiesta solo se completa con un token segreto che il sito stesso ha inviato al browser e che (a causa del SOP) non è accessibile a nessun'altra scheda tranne quella che mostra la vittima sito.

Se c'era SOP, ma nessun CSRF, e tutte le informazioni necessarie (id utente, ecc.) erano disponibili per il sito malvagio direttamente o tramite semplice forzatura bruta, il sito malvagio poteva inviare il browser al server della vittima un comando che dovrebbe essere rispettato (ad esempio "aggiungi [email protected] al gruppo degli amministratori attendibili").

Quindi potresti dire che SOP è ciò che rende CSRF funzionante.

A causa del modo in cui viene implementata la protezione CSRF (ad esempio come valore di un modulo nascosto impostato dal server) se un'origine malvagia può leggere le risposte ricevute dal tuo browser da facebook.com, sarà in grado di inviare un modulo a Facebook con il token CSRF corretto, evitando così la protezione CSRF di Facebook. Poiché lo stesso criterio di origine impedisce ad altri domini di leggere le risposte del browser da facebook.com, questo attacco è, per impostazione predefinita, non possibile.