È sicuro impostare il valore dell'intestazione "Access Control Allow Origin" sul valore dell'intestazione "Origin" che è implicitamente impostato dal browser?

Se il server rispecchia semplicemente l'origine fornita dal cliente nell'intestazione Access-Control-Allow-Origin della risposta senza ulteriori verifiche, in sostanza consente a qualsiasi terza parte di accedere all'origine incrociata della risorsa, ovvero sarebbe un problema di sicurezza se l'accesso di origine incrociata deve essere limitato.

Tuttavia, se questo mirroring viene eseguito solo dopo verifiche aggiuntive, ad esempio solo se il client è autorizzato, questo è meno problematico. Anche se potrebbero esserci casi in cui può essere un problema anche in questo caso.

In sintesi: se questo è un problema o meno dipende da informazioni che non sono fornite nella domanda.

La vulnerabilità che hai notato si chiama CORS errata configurazione. C'è un buon post sul blog di PortSwigger (Guys behind Burp suite) che parla sullo stesso argomento.

Prima di andare avanti e provare a rispondere a questa domanda, penso che alcuni punti debbano essere collegati.

Nozioni di base

La politica della stessa origine (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 una risorsa proveniente da un'altra origine. Fondamentalmente, SOP impedisce che gli script in esecuzione in un'unica origine provengano da dati di lettura di un'altra origine. In alcuni casi è necessario che un'app consenta altre origini per l'accesso alle risorse. Ciò si ottiene utilizzando la condivisione delle risorse di origine incrociata. Potrebbero esserci potenziali problemi di sicurezza dovuti a errate configurazioni CORS.

Il problema

Ora, siamo consapevoli che il CORS può essere utilizzato per consentire l'accesso ai dati di origine incrociata in modo controllato utilizzando le intestazioni di Access-Control. Tuttavia, c'è un problema. Il Access-Control-Allow-Origin header funziona bene se hai bisogno di fidarti solo un dominio di terze parti con accesso ai dati. Tuttavia, potrebbero esserci casi in cui è necessario fornire una lista bianca di domini per accedere a più domini. Questo è dove sta il problema. Nessuno dei browser supporta la specifica di più origini nell'intestazione Access-Control. Non puoi nemmeno coprire sottodomini usando i caratteri jolly, ad es.

Access-Control-Allow-Origin: abc.com xyz.com (NOT SUPPORTED)

Access-Control-Allow-Origin: *.example.com (NOT SUPPORTED)

Ciò ha costretto molti sviluppatori a utilizzare il valore dell'intestazione di origine dalla richiesta HTTP e a generare dinamicamente l'intestazione Access-Control-Allow-Origin per fornire l'accesso richiesto. In pratica il valore dell'intestazione Origin inviato nella richiesta viene riflesso nell'intestazione Access-Control-Allow-Origin reponse (Per una spiegazione dettagliata, fai riferimento al post sul blog qui sopra)

Questo comportamento viola uno dei principi di base della sicurezza:

All data coming from the client should be treated as untrusted until validated.

The Vulnerability

Questo comportamento sostanzialmente sconfigge lo scopo della politica Same-Origin. Poiché l'intestazione Access-Control-Allow-Origin può essere controllata dal client, qualsiasi dominio dannoso può ora richiedere dati dall'applicazione Web di destinazione e leggere la risposta. L'unica condizione è che l'utente target debba avere il sito di destinazione e il sito malevolo aperto nello stesso browser contemporaneamente con una sessione autenticata con il sito di destinazione. Ciò fornisce accesso illimitato al sito malevolo permettendogli di eseguire tutti i tipi di azioni dell'utente e acquisire dati utente.

Questa è una vulnerabilità difficile da risolvere e, a meno che i browser non offrano un supporto migliore alle opzioni di white list di CORS, è necessario convalidare a livello di codice il dominio richiedente prima di consentire l'accesso all'origine incrociata.