HTTP-Anfragen enthalten Header wie „User-Agent“ oder „Content-Type“. Abgesehen von den Headern, die von Browsern angehängt werden, können Android-Apps zusätzliche Header wie Cookie oder Referrer über den Intent EXTRA_HEADERS hinzufügen. Aus Sicherheitsgründen filtert Chrome einige der zusätzlichen Header abhängig davon, wie und wo ein Intent gestartet wird.
Cross-Origin-Anfragen erfordern eine zusätzliche Sicherheitsebene, da Client und Server nicht derselben Partei gehören. In diesem Leitfaden wird erläutert, wie solche Anfragen über benutzerdefinierte Tabs in Chrome gestartet werden, d.h. Intents, die von Apps gestartet werden, die eine URL auf dem Browsertab öffnen. Bis Chrome 83 konnten Entwickler beim Starten eines benutzerdefinierten Tabs beliebige Header hinzufügen. Ab Version 83 filtert Chrome alle ursprungsübergreifenden Header mit Ausnahme der ursprungsübergreifenden Header auf der Zulassungsliste, da Header, die nicht auf der Zulassungsliste stehen, ein Sicherheitsrisiko darstellen. Ab Chrome 86 ist es möglich, Header ohne Genehmigungsliste an ursprungsübergreifende Anfragen anzuhängen, wenn Server und Client über einen Link für digitale Assets miteinander verbunden sind. Dieses Verhalten wird in der folgenden Tabelle zusammengefasst:
| Chrome-Version | CORS-Header zulässig |
|---|---|
| Vor Chrome 83 | auf der Zulassungsliste, nicht auf der Zulassungsliste |
| Chrome 83 bis Chrome 85 | auf der Zulassungsliste |
| ab Chrome 86 | Auf der Zulassungsliste, nicht auf der Zulassungsliste, wenn ein digitaler Asset-Link eingerichtet wird |
Tabelle 1: Filtern von CORS-Headern, die nicht auf der Zulassungsliste stehen.
In diesem Artikel erfahren Sie, wie Sie eine bestätigte Verbindung zwischen dem Server und dem Client einrichten und diese verwenden, um HTTP-Header mit und ohne Genehmigung zu senden. Für den Code können Sie mit Zusätzliche Header zu benutzerdefinierten Tab-Intents hinzufügen fortfahren.
Hintergrund
CORS-Anfrageheader auf der Zulassungsliste im Vergleich zu nicht auf der Zulassungsliste befindlichen CORS-Anfrageheadern
Mit Cross-Origin Resource Sharing (CORS) kann eine Webanwendung von einem Ursprung Ressourcen eines anderen Ursprungs anfordern. Die Liste der Header auf der CORS-Liste der Genehmigungen wird im HTML-Standard verwaltet. In der folgenden Tabelle sehen Sie Beispiele für Header, die auf der Zulassungsliste stehen:
| Header | Beschreibung |
|---|---|
| Sprache akzeptieren | bewirbt natürliche Sprachen, die der Kunde versteht. |
| Inhaltssprache | beschreibt die für die aktuelle Zielgruppe vorgesehene Sprache |
| Inhaltstyp | gibt den Medientyp der Ressource an |
Tabelle 2: Beispiel für CORS-Header auf der Zulassungsliste
Die Header in der Zulassungsliste gelten als sicher, da sie keine vertraulichen Nutzerinformationen enthalten und wahrscheinlich nicht dazu führen, dass der Server potenziell schädliche Vorgänge ausführt.
In der folgenden Tabelle finden Sie Beispiele für Header, die nicht auf der Zulassungsliste stehen:
| Header | Beschreibung |
|---|---|
| Inhabertoken | authentifiziert den Client auf einem Server |
| origin | gibt den Ursprung der Anfrage an |
| Keks | enthält Cookies, die vom Server gesetzt wurden |
Tabelle 3: Beispiel für CORS-Header ohne Genehmigungsliste
Der HTML-Standard rät davon ab, Header ohne Genehmigungsliste an CORS-Anfragen anzuhängen. Server gehen davon aus, dass ursprungsübergreifende Anfragen nur Header enthalten, die auf der Zulassungsliste stehen. Wenn Header ohne Genehmigungsliste von ursprungsübergreifenden Domains gesendet werden, können schädliche Drittanbieter-Apps Header erstellen, die Nutzercookies missbrauchen, die von Chrome (oder einem anderen Browser) gespeichert und an Anfragen angehängt werden. Die Cookies könnten schädliche Servertransaktionen authentifizieren, die andernfalls nicht möglich wären.
CORS-Genehmigungslisten-Header an Anfragen für benutzerdefinierte Tabs anhängen
Benutzerdefinierte Tabs sind eine spezielle Möglichkeit, Webseiten in einem benutzerdefinierten Browsertab zu öffnen. Intents für benutzerdefinierte Tabs können mit CustomTabsIntent.Builder() erstellt werden. Sie können auch Header mit einem Bundle mit dem Flag Browser.EXTRA_HEADERS an diese Intents anhängen:
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"));
Wir können solche Header jederzeit an CORS-Anfragen auf benutzerdefinierten Tabs anhängen. In Chrome werden Header, die nicht auf der Zulassungsliste stehen, jedoch standardmäßig herausgefiltert. Auch wenn das Verhalten anderer Browser möglicherweise anders ist, sollten Entwickler damit rechnen, dass Header ohne Genehmigungsliste generell blockiert werden.
Um Header ohne Genehmigung in benutzerdefinierte Tabs einzuschließen, muss zuerst die ursprungsübergreifende Verbindung über einen Link für den digitalen Zugriff geprüft werden. Im nächsten Abschnitt erfahren Sie, wie Sie diese einrichten und einen Intent für benutzerdefinierte Tabs mit den erforderlichen Headern starten.
Benutzerdefinierte Tab-Intents zusätzliche Header hinzufügen
Digitale Asset-Links einrichten
Damit Header, die nicht auf der Zulassungsliste stehen, über Intents für benutzerdefinierte Tabs übergeben werden können, muss eine Verknüpfung mit digitalen Assets zwischen der Android-App und der Webanwendung eingerichtet werden, die bestätigt, dass der Autor der Inhaber beider Apps ist.
Folgen Sie dem offiziellen Leitfaden, um einen Link für digitale Assets einzurichten. Verwenden Sie für die Linkbeziehung „delegate_permission/common.use_as_origin“, um anzugeben, dass beide Apps nach der Bestätigung des Links demselben Ursprung angehören.
Benutzerdefinierten Tab-Intent mit zusätzlichen Headern erstellen
Es gibt mehrere Möglichkeiten, einen Intent für benutzerdefinierte Tabs zu erstellen. Sie können den in androidX verfügbaren Builder verwenden, indem Sie die Bibliothek den Build-Abhängigkeiten hinzufügen:
MULTI_LINE_CODE_PLACEHOLDER_1
Erstellen Sie den Intent und fügen Sie zusätzliche Header hinzu:
MULTI_LINE_CODE_PLACEHOLDER_2
Verbindung für benutzerdefinierte Tabs einrichten, um die Asset-Verknüpfung zu prüfen
Eine Verbindung für benutzerdefinierte Tabs wird zum Einrichten einer CustomTabsSession zwischen der App und dem Chrome-Tab verwendet. Wir benötigen die Sitzung, um zu prüfen, ob App und Web-App zum selben Ursprung gehören.
Die Überprüfung besteht nur dann erfolgreich, wenn die Verknüpfungen mit digitalen Assets korrekt eingerichtet wurden.
Es wird empfohlen, CustomTabsClient.warmup() aufzurufen. Dadurch kann die Browseranwendung im Hintergrund vorinitialisiert werden und der URL-Öffnenvorgang wird beschleunigt.
MULTI_LINE_CODE_PLACEHOLDER_3
Callback einrichten, der den Intent nach der Validierung startet
Die CustomTabsCallback wurde an die Sitzung übergeben. Wir haben onRelationshipValidationResult() so eingerichtet, dass die zuvor erstellte CustomTabsIntent gestartet wird, sobald die Ursprungsüberprüfung erfolgreich war.
MULTI_LINE_CODE_PLACEHOLDER_4
Dienstverbindung für benutzerdefinierte Tabs binden
Durch das Binden des Dienstes wird der Dienst gestartet und der onCustomTabsServiceConnected() der Verbindung wird schließlich aufgerufen. Vergessen Sie nicht, die Bindung des Dienstes entsprechend aufzuheben. Das Binden und Aufheben der Bindung erfolgt in der Regel in den Methoden des Aktivitätslebenszyklus onStart() und 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);
Code der Demoanwendung
Weitere Informationen zum Dienst für benutzerdefinierte Tabs Eine funktionierende Beispiel-App finden Sie im GitHub-Repository android-browser-helper.
Zusammenfassung
In diesem Leitfaden wird gezeigt, wie Sie CORS-Anfragen auf benutzerdefinierten Tabs beliebige Header hinzufügen können. Header auf der Genehmigungsliste können an jede CORS-Anfrage für benutzerdefinierte Tabs angehängt werden. Header, die nicht auf der Zulassungsliste stehen, werden in CORS-Anfragen im Allgemeinen als unsicher eingestuft und werden von Chrome standardmäßig herausgefiltert. Sie können nur von Clients und Servern desselben Ursprungs hinzugefügt werden, der durch einen Link für digitale Assets verifiziert wird.