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'attributo Intent extra EXTRA_HEADERS
. Per motivi di sicurezza, Chrome filtra alcune delle intestazioni aggiuntive, a seconda di come e dove viene lanciato un'intent.
Le richieste cross-origin richiedono un livello di sicurezza aggiuntivo perché 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 gli intent avviati da app che aprono un URL nella scheda del browser. Fino a Chrome 83, gli sviluppatori potevano aggiungere qualsiasi intestazione al momento dell'avvio di una scheda personalizzata. A partire dalla versione 83, Chrome ha iniziato a filtrare tutte le intestazioni cross-origin, ad eccezione di quelle incluse nell'elenco approvato, poiché quelle non incluse nell'elenco approvato rappresentavano un rischio per la sicurezza. A partire da Chrome 86, è possibile associare intestazioni non incluse nell'elenco approvato 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, non nella lista 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 schede personalizzate.
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 CORS-approvedlist è gestito nello standard HTML. Nella tabella seguente sono riportati alcuni esempi di intestazioni incluse nella lista consentita:
Header | Descrizione |
---|---|
accept-language | pubblicizza le lingue naturali che il cliente comprende |
content-language | 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 incluse nell'elenco approvato.
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 incluse nell'elenco approvato nelle schede personalizzate è verificare innanzitutto la connessione cross-origin 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 aggiuntive 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 web e quella per Android che verifichi che l'autore possieda entrambe le applicazioni.
Segui la guida ufficiale per configurare un link a un asset digitale. Per la relazione del link, 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 di Custom Tabs. Puoi utilizzare il generatore disponibile in androidX aggiungendo la libreria alle dipendenze di build:
MULTI_LINE_CODE_PLACEHOLDER_1
Crea l'intent e aggiungi intestazioni aggiuntive:
MULTI_LINE_CODE_PLACEHOLDER_2
Configurare una connessione di schede personalizzate per convalidare il link dell'asset
Una connessione Custom Tabs viene utilizzata per configurare un CustomTabsSession
tra l'app e la scheda 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 invitiamo a chiamare CustomTabsClient.warmup()
. Consente all'applicazione del browser di preinizializzarsi in background e di velocizzare la procedura 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 onCustomTabsServiceConnected()
della connessione verrà chiamato alla fine. Non dimenticare di annullare il binding del servizio in modo appropriato. 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
Puoi trovare ulteriori dettagli sul servizio Custom Tabs 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. L'attacco è consentito solo per client e server della stessa origine, verificati da un link all'asset digitale.