Access-control-allow-origin: * con un token al portatore

Ci sono alcune cose che significano che lo sfruttamento è improbabile.

Per iniziare con

access-control-allow-credentials: true
access-control-allow-origin: *

è una combinazione non valida :

Important note: when responding to a credentialed request, server must specify a domain, and cannot use wild carding. The above example would fail if the header was wildcarded as: Access-Control-Allow-Origin: *. Since the Access-Control-Allow-Origin explicitly mentions http://foo.example, the credential-cognizant content is returned to the invoking web content.

Un'altra cosa è che il l'intestazione di autorizzazione non è una semplice intestazione , quindi richiederebbe una verifica preliminare che restituisca un Access-Control-Allow-Headers risposta che restituisce quell'intestazione. Il server che non restituisce questo impedisce anche qualsiasi attacco CSRF, perché il pre-volo lo bloccherà.

A meno che non permetta l'intestazione, di solito non è possibile aggiungere un'intestazione incrociata personalizzata dell'intestazione a meno che non sia tenta un exploit con Flash utilizzato per funzionare su determinati browser.

What are the risks with this model? Is this a sensible way to do things?

Poiché non è valido specificare questa combinazione di intestazioni, in realtà questo non è un modo ragionevole di fare le cose. Ci potrebbe essere qualche browser straniero che lo permetterebbe e il sito sarebbe vulnerabile (se una potenziale vittima dovesse usarlo). Permettere tutte le origini ma non le richieste credenziali consente al browser vittima di essere usato come una sorta di proxy per raggiungere altrimenti risorse inaccessibili. Tuttavia, poiché l'intestazione del portatore non può essere collegata (senza un exploit Flash) e consentita attraverso Access-Control-Allow-Headers , non direi che questo è ad alto rischio. Inoltre, poiché l'attaccante non ha il token al portatore della propria vittima, qualsiasi richiesta cross-domain che verrebbe fatta sarebbe sotto la sessione dell'attaccante piuttosto che della vittima.

Probabilmente lo farei notare come un elemento consultivo che dovrebbero verificare che le intestazioni CORS corrispondano alle loro intenzioni.

Toker del portatore IMO + CORS permissivo mescola due decisioni sbagliate in una che è potenzialmente disastrosa.

L'approccio token bearer aumenta notevolmente l'esposizione dei token tramite (1) le comunicazioni di rete, facendo affidamento su TLS per essere configurato correttamente, e (2) sul terminale utente (browser, dispositivo mobile) dove il token dovrà essere protetto e gestito con cura.

Sfortunatamente, l'impostazione permissiva di CORS aggrava ulteriormente i loro problemi di sicurezza nei confronti dei clienti. Poiché l'agente utente è autorizzato a connettersi a qualsiasi altro dominio per scaricare le librerie JS, è meglio assicurarsi che questi altri siti non siano solo affidabili ma dotati di un'eccellente sicurezza, in modo che non possano essere facilmente compromessi. Non vuoi che il token che risiede nell'agente utente venga rubato da qualche script malevolo scaricato da qualche altro sito - questo è il rischio che si presenta quando si combinano queste due scelte.

Consigli per mitigare il furto di token:

• Se il token bearer è assolutamente necessario, limita CORS per impedire l'accesso tra domini.
• D'altra parte se è necessario il dominio incrociato, utilizzare la concessione del codice di autorizzazione in cui il token risiede interamente sul lato server e non viene mai esposto al programma utente.