Le richieste HTTP contengono intestazioni come User-Agent o Content-Type. Oltre alle intestazioni allegate dai browser, le app per Android possono aggiungere intestazioni aggiuntive, come Cookie o Referrer, tramite l'extra Intent EXTRA_HEADERS. Per motivi di sicurezza, Chrome filtra alcune delle intestazioni aggiuntive, a seconda di come e dove viene avviato un'intent.
Le richieste multiorigine richiedono un ulteriore livello di sicurezza, poiché il client e il server non sono di proprietà della stessa parte. Questa guida illustra l'avvio di queste richieste tramite le schede personalizzate di Chrome, ovvero intent avviati da app che aprono un URL nella scheda del browser. Fino a Chrome 83, gli sviluppatori potevano aggiungere qualsiasi intestazione all'avvio di una scheda personalizzata. A partire dalla versione 83, Chrome ha iniziato a filtrare tutte le intestazioni multiorigine tranne quelle approvate, poiché le intestazioni non approvate rappresentavano un rischio per la sicurezza. A partire da Chrome 86, è possibile associare intestazioni non incluse nell'elenco di quelle approvate alle richieste cross-origin, quando il server e il client sono collegati tramite un link a risorse digitali. Questo comportamento è riassunto nella seguente tabella:
| Versione di Chrome | Intestazioni CORS consentite |
|---|---|
| prima di Chrome 83 | approvelisted, non-approvelisted |
| Da Chrome 83 a Chrome 85 | nella lista consentita |
| a partire da Chrome 86 | nella lista consentita, nella lista non consentita quando è configurato un link a un asset digitale |
Tabella 1: Filtro delle intestazioni CORS non incluse nell'elenco approvato.
Questo articolo mostra come configurare una connessione verificata tra il server e il client e utilizzarla per inviare intestazioni HTTP sia approvate che non approvate. Per il codice, puoi andare ad Aggiunta di intestazioni aggiuntive agli intent di scheda personalizzata.
Sfondo
Intestazioni delle richieste CORS nell'elenco approvato e non nell'elenco approvato
La condivisione delle risorse tra origini (CORS) consente a un'applicazione web di un'origine di richiedere risorse di un'altra origine. L'elenco delle intestazioni Approvate da CORS viene mantenuto nello standard HTML. Nella tabella seguente sono riportati alcuni esempi di intestazioni nella lista consentita:
| Header | Descrizione |
|---|---|
| accept-language | pubblicizza le lingue naturali che il cliente comprende |
| lingua dei contenuti | descrive il linguaggio destinato al pubblico attuale |
| content-type | indica il tipo di media della risorsa |
Tabella 2: Esempi di intestazioni CORS inserite nella lista consentita.
Le intestazioni nell'elenco approvato sono considerate sicure perché non contengono informazioni sensibili degli utenti e non è probabile che causino l'esecuzione di operazioni potenzialmente dannose da parte del server.
Nella tabella seguente sono riportati alcuni esempi di intestazioni non incluse nell'elenco approvato:
| Header | Descrizione |
|---|---|
| bearer-token | autentica il client su un server |
| origine | indica l'origine della richiesta |
| biscotto | contiene cookie impostati dal server |
Tabella 3: Esempi di intestazioni CORS non approvate.
L'attacco di intestazioni non incluse nell'elenco di approvazioni alle richieste CORS è sconsigliato dallo standard HTML e i server assumono che le richieste cross-origin contengano solo intestazioni incluse nell'elenco di approvazioni. L'invio di intestazioni non incluse nell'elenco approvato da domini cross-origin consentirebbe ad app di terze parti malintenzionate di creare intestazioni che fanno un uso improprio dei cookie degli utenti memorizzati e allegati a Chrome (o a un altro browser) dalle richieste. I cookie potrebbero autenticare transazioni del server dannose che altrimenti non sarebbero possibili.
Attacco delle intestazioni nell'elenco approvato CORS alle richieste di Custom Tabs
Le schede personalizzate sono un modo speciale per avviare pagine web in una scheda del browser personalizzata. Puoi creare intent di schede personalizzate utilizzando CustomTabsIntent.Builder(). Puoi anche associare intestazioni a questi scopi utilizzando un Bundle con il flag Browser.EXTRA_HEADERS:
CustomTabsIntent intent = new CustomTabsIntent.Builder(session).build();
Bundle headers = new Bundle();
headers.putString("bearer-token", "Some token");
headers.putString("redirect-url", "Some redirect url");
intent.intent.putExtra(Browser.EXTRA_HEADERS, headers);
intent.launchUrl(Activity.this, Uri.parse("http://www.google.com"));
Possiamo sempre allegare intestazioni nell'elenco delle approvate alle richieste CORS delle schede personalizzate. Tuttavia, Chrome filtra per impostazione predefinita le intestazioni non incluse nella lista approvata. Sebbene altri browser possano avere un comportamento diverso, gli sviluppatori devono aspettarsi che le intestazioni non incluse nella lista approvata vengano bloccate in generale.
Il modo supportato per includere intestazioni non approvate nelle schede personalizzate consiste nel verificare innanzitutto la connessione multiorigine utilizzando un link di accesso digitale. La sezione successiva mostra come configurarli e lanciare un'intenzione di Custom Tabs con le intestazioni richieste.
Aggiunta di intestazioni extra agli intent di schede personalizzate
Configurare i link agli asset digitali
Per consentire il passaggio di intestazioni non incluse nell'elenco approvato tramite gli intent di scheda personalizzata, è necessario impostare un collegamento di asset digitali tra l'applicazione Android e quella web che verifichi che l'autore possieda entrambe le applicazioni.
Segui la guida ufficiale per configurare un link a una risorsa digitale. Per la relazione di collegamento, utilizza "delegate_permission/common.use_as_origin" che indica che entrambe le app appartengono alla stessa origine una volta verificato il collegamento.
Creare un intent di scheda personalizzata con intestazioni aggiuntive
Esistono diversi modi per creare un intent delle schede personalizzate. Puoi utilizzare il generatore disponibile in androidX aggiungendo la libreria alle dipendenze di build:
MULTI_LINE_CODE_PLACEHOLDER_1
Crea l'intent e aggiungi altre intestazioni:
MULTI_LINE_CODE_PLACEHOLDER_2
Configurare una connessione di schede personalizzate per convalidare il link dell'asset
La connessione Schede personalizzate viene utilizzata per configurare un CustomTabsSession tra l'app e la
scheda di Chrome. Abbiamo bisogno della sessione per verificare che l'app e l'app web appartengano alla stessa origine.
La verifica viene superata solo se i link agli asset digitali sono stati configurati correttamente.
Ti consigliamo di chiamare CustomTabsClient.warmup(). Consente all'applicazione del browser di pre-inizializzare in background e di velocizzare il processo di apertura dell'URL.
MULTI_LINE_CODE_PLACEHOLDER_3
Configurare un callback che avvii l'intent dopo la convalida
CustomTabsCallback è stato passato alla sessione. Abbiamo configurato il suo
onRelationshipValidationResult() per lanciare il CustomTabsIntent creato in precedenza
una volta completata la verifica dell'origine.
MULTI_LINE_CODE_PLACEHOLDER_4
Collega la connessione al servizio delle schede personalizzate
L'associazione del servizio avvia il servizio e, alla fine, verrà chiamato onCustomTabsServiceConnected()
della connessione. Non dimenticare di slegare in modo appropriato il servizio. La creazione e lo scollegamento di associazioni avviene in genere nei metodi di ciclo di vita dell'attività onStart() e onStop().
// Bind the custom tabs service connection.
// Call this in onStart()
CustomTabsClient.bindCustomTabsService(this,
CustomTabsClient.getPackageName(MainActivity.this, null), connection);
// …
// Unbind the custom tabs service.
// Call this in onStop().
unbindService(connection);
Codice dell'applicazione demo
Per ulteriori dettagli sul servizio Schede personalizzate, fai clic qui. Consulta il repository GitHub android-browser-helper per un'app di esempio funzionante.
Riepilogo
Questa guida ha mostrato come aggiungere intestazioni arbitrarie alle richieste CORS di schede personalizzate. le intestazioni nell'elenco approvato possono essere allegate a ogni richiesta CORS di schede personalizzate. Le intestazioni non incluse nell'elenco approvato sono generalmente considerate non sicure nelle richieste CORS e Chrome le filtra per impostazione predefinita. Il collegamento è consentito solo per client e server della stessa origine, verificati da un collegamento agli asset digitali.