In che modo CSRF è correlato alla stessa politica di origine

Iniziamo definendo il termine origine. L'origine di una pagina è decisa da tre fattori unici: nome host, protocollo e numero di porta. Ad esempio, http://test.com e https://test.com hanno origini diverse in quanto il protocollo è diverso. Allo stesso modo http://one.test.com e http://two.test.com hanno origini diverse poiché gli hostname sono diversi. La proprietà di origine è diversa anche per due servizi in esecuzione sullo stesso host con numeri di porta diversi, ad es. http://test.com:8081 e http://test.com:8082 sono considerati origini diverse.

Same Origin Policy (SOP) è un controllo di sicurezza a livello di browser che stabilisce in che modo un documento o uno script appartenente a un'origine può interagire con risorse di un'altra origine. Fondamentalmente, impedisce agli script in esecuzione sotto un'origine di leggere i dati da un'altra origine .

Le richieste di domini incrociati e l'invio di moduli sono ancora consentiti, ma non è consentita la lettura di dati da un'altra origine. Ciò significa che se si sta eseguendo un attacco CSRF su un sito vulnerabile che provoca alcune modifiche allo stato del lato server (ad es. Creazione dell'utente, eliminazione di documenti, ecc.), L'attacco avrà esito positivo ma non si sarà in grado di leggere la risposta.

In breve SOP impedisce solo di leggere i dati che sono stati serviti da un'origine diversa. Non copre gli invii di moduli interdominio che vengono utilizzati per effettuare un attacco CSRF.

Per quanto riguarda l'esecuzione della comunicazione interdominio usando AJAX, ci sono alcuni altri controlli di sicurezza che dettano la comunicazione. Fai riferimento a Condivisione delle risorse incrociate di origine . CORS consente a origini diverse di comunicare e condividere i dati in modo controllato e l'errata configurazione di CORS può anche risultare in vulnerabilità della sicurezza .

Si noti che SOP non impedisce che le risorse ospitate su domini diversi vengano incorporate in una pagina utilizzando tag script, tag CSS e immagine. Mentre questo potrebbe non consentire una lettura diretta dei contenuti, gli effetti collaterali del caricamento e del rendering possono essere utilizzati per determinare (parti del) il contenuto. Nota anche che i Websocket non sono coperti da SOP e quindi è possibile la lettura cross-site.

P.S. Tratto dal mio blog .

Same Origin Policy (SOP) preserves the data of other domains...

Ci sono due parti del SOP:

1. Impedisce agli script sull'origine A di leggere i dati dall'origine B.
2. Impedisce ai siti di origine A di inviare qualsiasi cosa tranne le cosiddette richieste "semplici" all'origine B. Le richieste semplici sono limitate a GET e POST e solo poche intestazioni possono essere modificate.

...and therefore nulls out the use of CSRF.

Il SOP non protegge contro CSRF. Perché?

1. Un attacco CSRF viene eseguito inviando una richiesta e non leggendo nulla dalla risposta. Di fatto, non puoi né devi leggere la risposta.
2. Normalmente utilizzi richieste semplici in un attacco CSRF.

Come puoi vedere, le limitazioni sopra menzionate che il SOP mette in atto non impediscono gli attacchi CSRF.

Now considering the Same Origin Policy only applies to XMLHTTPRequest...

No, non è così. Si applica a tutti i dati gestiti da un browser. Se si utilizza XMLHTTPRequest, un modulo ordinario o l'API di recupero è irrilevante. Si applicano le stesse restrizioni.

...so with a cleverly crafted form, I can do a POST request witch voids the SOP and hence the need for CSRF tokens.

Con un modulo ingegnoso puoi fare una richiesta POST che esegue un attacco CSRF, sì. Ed è per questo che hai bisogno di una protezione speciale, come i token CSRF.

Now with all of this, does the CSRF kind of work around the SOP or works through it?

Non sono sicuro di cosa significhi "aggirare" o "elaborare" il SOP. Invece, lasciami dire questo: CSRF è possibile perché i browser ti permettono di inviare richieste POST di origine incrociata.

Un sito A può causare una richiesta al diverso sito B in vari modi, per esempio includendo un'immagine dal sito B all'interno dell'HTML dal sito A (cioè <img src=http://B/... >) o fai cose simili con moduli o Javascript o reindirizzamenti HTTP. Le richieste avviate da un sito ma indirizzate a un altro sito sono chiamate richieste cross-site.

La falsificazione richiesta tra siti (CSRF) significa che una richiesta cross-site può essere utilizzata in modo improprio. Ciò avviene in genere perché un cookie di sessione esistente da una precedente connessione al sito B viene inviato a ciascuna richiesta su questo sito, anche se la richiesta viene avviata dal sito A, cioè tra siti diversi. Ciò significa che la richiesta viene eseguita con l'identità dell'utente registrato nella parte B. Un attacco CSRF riuscito significa che tale richiesta cross-site può causare danni, ad esempio da modifica delle impostazioni DNS in un router vulnerabile a CSRF .

La politica Same-Origin (SOP) non rende CSRF impossibile ma limita in qualche modo l'impatto di CSRF in quanto la richiesta viene inviata al sito B ma il risultato restituito dal server del sito B non può essere visto dall'attaccante. Quindi SOP rende CSRF solo in scrittura, cioè CSRF può essere utilizzato per eseguire azioni indesiderate ma non può essere usato da solo per estrarre dati dal sito B. Ad esempio, un utente malintenzionato esterno può utilizzare una vulnerabilità CSRF in una società interna Wiki per creare un nuovo postare nel nome di un utente esistente o eliminare un post, ma a causa di SOP non può leggere il contenuto del Wiki interno e inviarlo di nuovo all'attaccante esterno.

Si noti che non tutte le comunicazioni tra siti sono limitate dal SOP. In particolare Websocket non è limitato e quindi è possibile che un utente malintenzionato sul sito A utilizzi un browser come un trampolino per comunicare pienamente con un Websocket nel sito B con le autorizzazioni dell'utente connesso, ovvero scrivere e leggi i dati.