If it only prevents page/script from reading the response from another origin, can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser (where SOP is implemented)?
Questi sono due diversi tipi di attacco. Prevenire letture da un'altra origine impedisce al sito di un utente malintenzionato ( evil.example.com ) che l'utente ha visitato di effettuare una richiesta XHR al sito a cui l'utente ha effettuato l'accesso ( webmail.example.com ) e ottenere i dati. In questo caso, impedisce ad altri siti Web di leggere i messaggi e-mail dell'utente.
Se è possibile configurare il computer dell'utente per l'utilizzo di un proxy di intercettazione o se è possibile posizionare Wireshark in ascolto sulla modalità promiscua sulla rete dell'utente, è probabile che come utente malintenzionato non sia necessaria una richiesta XHR per più domini: è possibile basta osservare il traffico normale. Un'eccezione a questo è nel caso di attacchi come POODLE . Ad esempio, se si può ascoltare il traffico sulla rete, ma la connessione dell'utente viene effettuata sul sito Web tramite SSL, potrebbe essere necessario iniettare il traffico XHR come MITM per decrittografare un byte alla volta tramite il vettore di attacco POODLE.
La stessa politica di origine non aiuta qui, ma se non esistesse non ci sarebbe bisogno dell'attacco MITM e del vettore di POODLE. La stessa politica di origine difende da alcuni attacchi basati sul Web che sarebbero altrimenti possibili, niente di più.
Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?
Sì, sarebbe molto più sicuro se i server rispondessero solo alle richieste delle proprie origini. Tuttavia, questo romperebbe la maggior parte di Internet se fosse implementato come standard nelle nuove versioni dei server web. Sarebbe anche possibile creare un browser che non ha effettuato richieste di origine incrociata. Nessuno lo userà perché non funzionerà su molti siti.
In realtà puoi disabilitare i cookie di terze parti nella maggior parte dei browser. Questo in effetti renderebbe anonime le richieste AJAX di origine incrociata, in quanto nessun cookie sarebbe mai stato inviato. Sicuramente Chrome impedirà l'impostazione o la lettura dei cookie, altri browser potrebbero limitare l'impostazione di tali cookie. Ovviamente se viene utilizzato un altro metodo di autenticazione, come l'autenticazione HTTP di base, non può aiutarti qui. Tuttavia, se lo provi, per la maggior parte sarai in grado di vedere quale funzionalità si interrompe.
Why does the server even respond to such requests from another origin?
L'intestazione del browser Origin non viene letta fino a quando le intestazioni non vengono analizzate e, a quel punto, il browser ha già inviato cookie: qualsiasi restrizione sull'origine incrociata potrebbe essere implementata meglio a livello di browser perché un server Web non sarà in grado di bloccare il richiesta prima che venga inviata.
Consentire richieste di origine incrociata è il modo in cui le cose hanno funzionato storicamente e la sicurezza deve essere bilanciata con la compatibilità. CORS è stato progettato in modo tale che se il server non sceglie CORS, il livello di sicurezza è lo stesso che usare un browser pre-CORS. Prima di CORS era possibile per i siti effettuare richieste ad altri domini tramite script, ed è lo stesso ora. Se ci pensate dal punto di vista del server, una richiesta XHR GET equivale a includere un'immagine proveniente da un altro dominio usando un tag <img /> . Una richiesta POST XHR equivale a creare un modulo che invia a un altro dominio.
Potresti configurare il tuo server per bloccare queste richieste (ad esempio usando l'intestazione Origin), e questo è in realtà un modo valido per prevenire gli attacchi CSRF . Tuttavia, ciò dovrebbe essere fatto caso per caso, e va tenuto presente che la presenza di questa intestazione può variare tra browser e versioni (ad esempio, nessun supporto browser più vecchio).
Nota che questo non sarebbe di aiuto nel tuo esempio, dato che un MITM potrebbe, nella maggior parte dei casi, semplicemente falsificare l'origine.
Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?
Tutti i problemi relativi alle richieste di origine incrociata sono stati risolti in qualche modo, ad esempio i browser che seguono lo stesso criterio di origine e i siti Web che utilizzano token per impedire CSRF. Questo è il Web - non sicuro per impostazione predefinita. Se un sito Web è stato sviluppato pensando alla sicurezza, questi problemi possono essere superati.