In che modo l'impostazione di Origine su null in una richiesta CORS reindirizzato protegge da un attacco delegato confuso?

Questo paragrafo è scritto in modo teso e l'uso di "reindirizzamenti a un'altra risorsa in una nuova origine" nella prima frase non è del tutto corretto.

Ecco un semplice esempio forzato. Supponiamo che tu sia malintenzionato e che ci sia un'applicazione web che utilizza i servizi di un'API privilegiata tramite CORS, quindi l'origine dell'applicazione Web è considerata attendibile dall'API privilegiata. Supponiamo che tu voglia accedere ai dati dietro questa API privilegiata, ma la tua Origine ovviamente non è attendibile.

Crei un semplice servizio utile che offri tramite CORS e ottieni l'applicazione web per includere il tuo servizio in una pagina, qualsiasi pagina, sotto la sua origine attendibile. Quella pagina non ha bisogno di accedere all'API privilegiata.

(Naturalmente, quando sei nella pagina della tua vittima puoi fare tutto ciò che vuoi, ma avere pazienza con me.)

Se decidi di cambiare il tuo servizio CORS emettendo un 200 con alcuni dati per inviare un 3xx ai domini di risorse che incrociano le API privilegiate, questo crea un problema di affidabilità.

L'effettiva origine, la pagina che ha incorporato la tua risorsa, verrà considerata attendibile dall'API privilegiata. Ma non ha rilasciato la richiesta e potrebbe non voler parlare con l'API privilegiata in questo particolare momento.

Invece, hai emesso il reindirizzamento e, anche se in qualche modo ti sei fidato, in base all'origine, non ti fidi dell'API privilegiata. Se il browser segue il tuo 3xx e invia lungo l'Origine, ti arriva in modo illegittimo sulla fiducia data dall'API privilegiata all'origine.

Che cosa deve fare il browser? Una risposta ragionevole è di non seguire affatto il 3xx, ma ciò non consentirebbe l'uso di casi per i quali la fiducia non è preoccupante. L'emissione della richiesta con origine "nulla" consente tali casi d'uso, ma impedisce lo sfruttamento della fiducia che consentirebbe l'invio lungo l'intestazione Origin originale.

Guarda l'intestazione Origin in termini di difesa CSRF.

Diciamo a.com host ...

• un servizio che utilizza la intestazione Origin per bloccare gli attacchi CSRF ,
• e una pagina Web che richiede CORS a b.com .

Se l'origine è stata mantenuta dopo reindirizzamenti di origine incrociata, sarebbe possibile il seguente attacco CSRF:

1. Un utente accede al sito a.com .
2. L'utente visita una pagina che invia una richiesta CORS a b.com con Origin: https://a.com .
3. b.com risponde con un reindirizzamento a un endpoint protetto da CSRF su a.com .
4. Il browser dell'utente segue il reindirizzamento e richiede l'URL con Origin: https://a.com .

5. Il server a.com elabora la richiesta perché crede che sia originata da a.com , che non è completamente accurata perché ...

   • b.com ha avuto il pieno controllo sull'URL richiesto, inclusi i parametri di query.
   • qualsiasi dato nel corpo della richiesta sarebbe stato originariamente inteso per b.com , non a.com e il carico utile dei dati potrebbe essere stato elaborato con cura per essere dannoso quando viene inviato all'endpoint a.com . (Diciamo che era un POST con un reindirizzamento 307.)

Il fatto che a.com faccia richieste CORS a b.com non implica che si fida completamente di b.com .

Questo argomento è discusso in un bug di Chrome correlato: link

Se l'intestazione Origin conteneva un elenco di tutte le origini nella catena di reindirizzamento, potrebbe essere possibile creare applicazioni che tollerassero in modo sicuro i reindirizzamenti di origine incrociata. Sfortunatamente i produttori di browser non l'hanno mai implementato. Dallo stesso documento CORS per sviluppatori citato nella domanda:

Although the CORS specification implies that you can list multiple origins in the Access-Control-Allow-Origin header, in practice only a single value is allowed by all modern browsers. The multiple value syntax was intended to allow all origins in a redirect chain to be listed, as allowed by RFC6454, but this was never implemented.