Beibehalten des ursprünglichen HTTP-Hostnamens zwischen einem Reverseproxy und seiner Back-End-Webanwendung

Es wird empfohlen, den ursprünglichen HTTP-Hostnamen beizubehalten, wenn Sie einen Reverseproxy vor einer Webanwendung verwenden. Ein anderer Hostname am Reverseproxy als der Host, der dem Back-End-Anwendungsserver bereitgestellt wird, kann zu Cookies oder Umleitungs-URLs führen, die nicht ordnungsgemäß funktionieren. Beispielsweise kann der Sitzungszustand verloren gehen, die Authentifizierung kann fehlschlagen, oder Back-End-URLs können versehentlich für Endbenutzer verfügbar gemacht werden. Sie können diese Probleme vermeiden, indem Sie den Hostnamen der ursprünglichen Anforderung beibehalten, damit der Anwendungsserver dieselbe Domäne wie der Webbrowser sieht.

Dieser Leitfaden gilt insbesondere für Anwendungen, die in Plattform as a Service (PaaS)-Angeboten wie Azure App Service und Azure Spring Appsgehostet werden. Dieser Artikel enthält spezifische Implementierungsanleitungen für Azure Application Gateway, Azure Front Doorund Azure API Management, die häufig verwendete Reverseproxydienste sind.

Wenn End-to-End TLS/SSL erforderlich ist (die Verbindung zwischen dem Reverseproxy und dem Back-End-Dienst verwendet HTTPS), benötigt der Back-End-Dienst auch ein übereinstimmende TLS-Zertifikat für den ursprünglichen Hostnamen. Diese Anforderung erhöht die Betriebskomplexität bei der Bereitstellung und Verlängerung von Zertifikaten, aber viele PaaS-Dienste bieten kostenlose TLS-Zertifikate, die vollständig verwaltet werden.

Zusammenhang

Der Host einer HTTP-Anforderung

In vielen Fällen benötigt der Anwendungsserver oder eine Komponente in der Anforderungspipeline den Internetdomänennamen, der vom Browser für den Zugriff darauf verwendet wurde. Dies ist der Host der Anforderung. Es kann sich um eine IP-Adresse handeln, in der Regel handelt es sich jedoch um einen Namen wie contoso.com (der vom Browser dann mithilfe von DNS in eine IP-Adresse aufgelöst wird). Der Hostwert wird in der Regel von der Hostkomponente des Anforderungs-URIbestimmt, den der Browser als Host HTTP-Header an die Anwendung sendet.

In einigen Szenarien kann der ursprüngliche Hostheader geändert werden, insbesondere wenn ein HTTP-Reverseproxy in der Anforderungskette vorhanden ist, bevor er den Anwendungsserver erreicht. Ein Reverseproxy schließt die Clientnetzwerksitzung und richtet eine neue Verbindung zum Back-End ein. In dieser neuen Sitzung kann sie entweder den ursprünglichen Hostnamen der Clientsitzung übernehmen oder eine neue festlegen. Im letzteren Fall sendet der Proxy häufig weiterhin den ursprünglichen Hostwert in anderen HTTP-Headern, z. B. Forwarded oder X-Forwarded-Host. Mit diesem Wert können Anwendungen den ursprünglichen Hostnamen ermitteln, aber nur, wenn sie codiert sind, um diese Header zu lesen.

Warum Webplattformen den Hostnamen verwenden

Multitenant PaaS-Dienste erfordern häufig einen registrierten und validierten Hostnamen, um eine eingehende Anforderung an den Back-End-Server des entsprechenden Mandanten weiterzuleiten. Dies liegt daran, dass in der Regel ein gemeinsamer Pool von Lastenausgleichsmodulen vorhanden ist, der eingehende Anforderungen für alle Mandanten akzeptiert. Die Mandanten verwenden häufig den namen des eingehenden Hostnamens, um das richtige Back-End für den Kundenmandanten nachzuschlagen.

Um den Einstieg zu erleichtern, stellen diese Plattformen in der Regel eine Standarddomäne bereit, die vorkonfiguriert ist, um den Datenverkehr an Ihre bereitgestellte Instanz weiterzuleiten. Für App Service ist diese Standarddomäne azurewebsites.net. Jede Web-App, die Sie erstellen, erhält eine eigene Unterdomäne, z. B. contoso.azurewebsites.net. Ebenso wird die Standarddomäne für Azure Spring Apps azuremicroservices.io und azure-api.net für DIE API-Verwaltung.

Für Produktionsbereitstellungen verwenden Sie diese Standarddomänen nicht. Sie stellen stattdessen Ihre eigene Domäne bereit, um sich an die Marke Ihrer Organisation oder Anwendung anzupassen. Beispielsweise könnte contoso.com hinter den Kulissen in die contoso.azurewebsites.net Web App im App-Dienst aufgelöst werden, diese Domäne sollte jedoch nicht für einen Endbenutzer sichtbar sein, der die Website besucht. Dieser benutzerdefinierte contoso.com Hostname muss jedoch beim PaaS-Dienst registriert werden, damit die Plattform den Back-End-Server identifizieren kann, der auf die Anforderung reagieren soll.

Warum Anwendungen den Hostnamen verwenden

Zwei häufige Gründe, warum ein Anwendungsserver den Hostnamen benötigt, sind das Erstellen absoluter URLs und das Ausgeben von Cookies für eine bestimmte Domäne. Beispiel: Wenn der Anwendungscode folgendes ausführen muss:

• Zurückgeben einer absoluten anstelle einer relativen URL in der HTTP-Antwort (obwohl Websites in der Regel relative Links nach Möglichkeit rendern).
• Generieren Sie eine URL, die außerhalb der HTTP-Antwort verwendet werden soll, bei der relative URLs nicht verwendet werden können, z. B. zum Senden eines Links zur Website an einen Benutzer.
• Generieren Sie eine absolute Umleitungs-URL für einen externen Dienst. Beispielsweise an einen Authentifizierungsdienst wie die Microsoft Entra-ID, um anzugeben, wo er den Benutzer nach erfolgreicher Authentifizierung zurückgeben soll.
• Stellen Sie HTTP-Cookies aus, die auf einen bestimmten Host beschränkt sind, wie im Domain Attribut des Cookiesdefiniert.

Sie können all diese Anforderungen erfüllen, indem Sie den erwarteten Hostnamen zur Konfiguration der Anwendung hinzufügen und diesen statisch definierten Wert anstelle des eingehenden Hostnamens für die Anforderung verwenden. Dieser Ansatz erschwert jedoch die Anwendungsentwicklung und -bereitstellung. Außerdem kann eine einzelne Installation der Anwendung mehrere Hosts bedienen. Beispielsweise kann eine einzelne Web-App für mehrere Anwendungsmandanten verwendet werden, die alle über eigene eindeutige Hostnamen verfügen (z. B. tenant1.contoso.com und tenant2.contoso.com).

Und manchmal wird der name des eingehenden Hostnamens von Komponenten außerhalb des Anwendungscodes oder in Middleware auf dem Anwendungsserver verwendet, über den Sie nicht vollzugriff haben. Hier sind einige Beispiele:

• In App Service können Sie HTTPS- für Ihre Web-App erzwingen. Dies bewirkt, dass http-Anforderungen, die nicht sicher sind, an HTTPS umgeleitet werden. In diesem Fall wird der name des eingehenden Hostnamens verwendet, um die absolute URL für den Location Header der HTTP-Umleitung zu generieren.
• Azure Spring Apps verwendet ein ähnliches Feature, um HTTPS-zu erzwingen . Außerdem wird der eingehende Host verwendet, um die HTTPS-URL zu generieren.
• Der App-Dienst verfügt über eine ARR-Affinitätseinstellung, um Haftsitzungen zu aktivieren, sodass Anforderungen aus derselben Browserinstanz immer vom gleichen Back-End-Server bedient werden. Dies wird von den Front-Ends des App-Diensts ausgeführt, die der HTTP-Antwort ein Cookie hinzufügen. Die Domain des Cookies wird auf den eingehenden Host festgelegt.
• Der App-Dienst bietet Authentifizierungs- und Autorisierungsfunktionen, damit Benutzer sich problemlos anmelden und auf Daten in APIs zugreifen können.
  • Der eingehende Hostname wird verwendet, um die Umleitungs-URL zu erstellen, an die der Identitätsanbieter den Benutzer nach erfolgreicher Authentifizierung zurückgeben muss.
  • Aktivieren dieses Features wird standardmäßig auch die HTTP-to-HTTPS-Umleitungaktiviert. Auch hier wird der Name des eingehenden Hostnamens verwendet, um den Umleitungsspeicherort zu generieren.

Warum Sie möglicherweise versucht werden, den Hostnamen außer Kraft zu setzen

Angenommen, Sie erstellen eine Webanwendung in App Service, die über eine Standarddomäne von contoso.azurewebsites.netverfügt. (Oder in einem anderen Dienst wie Azure Spring Apps.) Sie haben keine benutzerdefinierte Domäne für App Service konfiguriert. Um einen Reverseproxy wie Application Gateway (oder einen ähnlichen Dienst) vor dieser Anwendung zu platzieren, legen Sie den DNS-Eintrag für contoso.com so fest, dass er in die IP-Adresse des Anwendungsgateways aufgelöst wird. Daher erhält sie die Anforderung für contoso.com vom Browser und ist so konfiguriert, dass diese Anforderung an die IP-Adresse weitergeleitet wird, auf die contoso.azurewebsites.net aufgelöst wird: dies ist der letzte Back-End-Dienst für den angeforderten Host. In diesem Fall erkennt App Service jedoch nicht die contoso.com benutzerdefinierte Domäne und lehnt alle eingehenden Anforderungen für diesen Hostnamen ab. Sie kann nicht bestimmen, wo die Anforderung weitergeleitet werden soll.

Es mag wie die einfache Möglichkeit aussehen, diese Konfiguration zu verwenden, darin besteht, den Host Header der HTTP-Anforderung im Anwendungsgateway außer Kraft zu setzen oder neu zu schreiben und auf den Wert von contoso.azurewebsites.netfestzulegen. Wenn Sie dies tun, sieht die ausgehende Anforderung vom Anwendungsgateway so aus, als ob die ursprüngliche Anforderung wirklich für contoso.azurewebsites.net anstelle von contoso.comvorgesehen war:

An diesem Punkt erkennt Der App-Dienst den Hostnamen und akzeptiert die Anforderung, ohne dass ein benutzerdefinierter Domänenname konfiguriert werden muss. Tatsächlich erleichtert Anwendungsgateway das Außerkraftsetzen des Hostheaders mit dem Host des Back-End-Pools. Azure Front Door funktioniert dies auch standardmäßig.

Das Problem mit dieser Lösung besteht jedoch darin, dass es zu verschiedenen Problemen führen kann, wenn die App den ursprünglichen Hostnamen nicht sieht.

Mögliche Probleme

Falsche absolute URLs

Wenn der ursprüngliche Hostname nicht beibehalten wird und der Anwendungsserver den eingehenden Hostnamen verwendet, um absolute URLs zu generieren, wird die Back-End-Domäne möglicherweise an einen Endbenutzer weitergegeben. Diese absoluten URLs können vom Anwendungscode oder, wie bereits erwähnt, durch Plattformfeatures wie die Unterstützung für die HTTP-zu-HTTPS-Umleitung in App Service und Azure Spring Apps generiert werden. Dieses Diagramm veranschaulicht das Problem:

1. Der Browser sendet eine Anforderung für contoso.com an den Reverseproxy.
2. Der Reverseproxy schreibt den Hostnamen in contoso.azurewebsites.net in der Anforderung an die Back-End-Webanwendung (oder in eine ähnliche Standarddomäne für einen anderen Dienst) um.
3. Die Anwendung generiert eine absolute URL, die auf dem eingehenden contoso.azurewebsites.net Hostname basiert, z. B. https://contoso.azurewebsites.net/.
4. Der Browser folgt dieser URL, die direkt zum Back-End-Dienst und nicht zum Reverseproxy bei contoso.comwechselt.

Dies kann sogar ein Sicherheitsrisiko darstellen, wenn der Reverseproxy auch als Webanwendungsfirewall fungiert. Der Benutzer erhält eine URL, die direkt zur Back-End-Anwendung wechselt und den Reverseproxy umgeht.

Falsche Umleitungs-URLs

Ein häufiger und spezifischerer Fall des vorherigen Szenarios tritt auf, wenn absolute Umleitungs-URLs generiert werden. Diese URLs sind für Identitätsdienste wie Microsoft Entra ID erforderlich, wenn Sie browserbasierte Identitätsprotokolle wie OpenID Connect, Open Authorization (OAuth) 2.0 oder SAML (Security Assertion Markup Language) 2.0 verwenden. Diese Umleitungs-URLs können vom Anwendungsserver oder middleware selbst oder, wie bereits erwähnt, von Plattformfeatures wie dem App-Dienst Authentifizierungs- und Autorisierungsfunktionengeneriert werden. Dieses Diagramm veranschaulicht das Problem:

1. Der Browser sendet eine Anforderung für contoso.com an den Reverseproxy.
2. Der Reverseproxy schreibt den Hostnamen in contoso.azurewebsites.net für die Anforderung an die Back-End-Webanwendung (oder in eine ähnliche Standarddomäne für einen anderen Dienst) um.
3. Die Anwendung generiert eine absolute Umleitungs-URL, die auf dem eingehenden contoso.azurewebsites.net Hostname basiert, z. B. https://contoso.azurewebsites.net/.
4. Der Browser wechselt zum Identitätsanbieter, um den Benutzer zu authentifizieren. Die Anforderung enthält die generierte Umleitungs-URL, um anzugeben, wo der Benutzer nach erfolgreicher Authentifizierung zurückgegeben werden soll.
5. Identitätsanbieter erfordern in der Regel, dass Umleitungs-URLs vorab registriert werden, daher sollte der Identitätsanbieter die Anforderung ablehnen, da die bereitgestellte Umleitungs-URL nicht registriert ist. (Es sollte nicht verwendet werden.) Wenn die Umleitungs-URL aus irgendeinem Grund registriert ist, leitet der Identitätsanbieter den Browser jedoch an die Umleitungs-URL weiter, die in der Authentifizierungsanforderung angegeben ist. In diesem Fall ist die URL https://contoso.azurewebsites.net/.
6. Der Browser folgt dieser URL, die direkt zum Back-End-Dienst und nicht zurück zum Reverseproxy wechselt.

Fehlerhafte Cookies

Ein Hostnamenkonflikt kann auch zu Problemen führen, wenn der Anwendungsserver Cookies ausgibt und den eingehenden Hostnamen verwendet, um das Domain Attribut des Cookie-zu erstellen. Das Domain-Attribut stellt sicher, dass das Cookie nur für diese bestimmte Domäne verwendet wird. Diese Cookies können durch den Anwendungscode oder, wie bereits erwähnt, durch Plattformfeatures wie den App-Dienst ARR-Affinitätseinstellunggeneriert werden. Dieses Diagramm veranschaulicht das Problem:

1. Der Browser sendet eine Anforderung für contoso.com an den Reverseproxy.
2. Der Reverseproxy schreibt den Hostnamen neu, der in der Anforderung an die Back-End-Webanwendung (oder in eine ähnliche Standarddomäne für einen anderen Dienst) contoso.azurewebsites.net werden soll.
3. Die Anwendung generiert ein Cookie, das eine Domäne basierend auf dem eingehenden contoso.azurewebsites.net Hostnamen verwendet. Der Browser speichert das Cookie für diese bestimmte Domäne und nicht die contoso.com Domäne, die der Benutzer tatsächlich verwendet.
4. Der Browser enthält das Cookie nicht für eine nachfolgende Anforderung für contoso.com, da die contoso.azurewebsites.net Domäne des Cookies nicht mit der Domäne der Anforderung übereinstimmt. Die Anwendung erhält das zuvor ausgestellte Cookie nicht. Daher kann der Benutzer den Zustand verlieren, der sich im Cookie befinden soll, oder Features wie ARR-Affinität funktionieren nicht. Leider generieren keine dieser Probleme einen Fehler oder sind für den Endbenutzer direkt sichtbar. Dies erschwert ihnen die Problembehandlung.

Implementierungsleitfaden für allgemeine Azure-Dienste

Um die hier beschriebenen potenziellen Probleme zu vermeiden, empfehlen wir, den ursprünglichen Hostnamen im Aufruf zwischen dem Reverseproxy und dem Back-End-Anwendungsserver beizubehalten:

Back-End-Konfiguration

Viele Webhostingplattformen erfordern, dass Sie die zulässigen eingehenden Hostnamen explizit konfigurieren. In den folgenden Abschnitten wird beschrieben, wie Sie diese Konfiguration für die am häufigsten verwendeten Azure-Dienste implementieren. Andere Plattformen bieten in der Regel ähnliche Methoden zum Konfigurieren von benutzerdefinierten Domänen.

Wenn Sie Ihre Webanwendung in App Service-hosten, können Sie einen benutzerdefinierten Domänennamen an die Web-App anfügen und vermeiden Sie die Verwendung des Standardmäßigen azurewebsites.net Hostnamens im Back-End. Sie müssen Ihre DNS-Auflösung nicht ändern, wenn Sie eine benutzerdefinierte Domäne an die Web-App anfügen: Sie können die Domäne überprüfen, indem Sie einen TXT Eintrag verwenden, ohne ihre regulären CNAME oder A Einträge zu beeinträchtigen. (Diese Einträge werden weiterhin in die IP-Adresse des Reverseproxys aufgelöst.) Wenn End-to-End TLS/SSL erforderlich ist, können Sie ein vorhandenes Zertifikat aus Key Vault- importieren oder ein App-Dienstzertifikat für Ihre benutzerdefinierte Domäne verwenden. (Beachten Sie, dass das kostenlose verwaltetes App Service-Zertifikat in diesem Fall nicht verwendet werden kann, da der DNS-Eintrag der Domäne zum direkten Auflösen in App Service und nicht zum Reverseproxy erforderlich ist.)

Ebenso können Sie, wenn Sie Spring Appsverwenden, eine benutzerdefinierte Domäne für Ihre App verwenden, um die Verwendung des azuremicroservices.io Hostnamens zu vermeiden. Sie können ein vorhandenes oder selbstsigniertes Zertifikat importieren, wenn End-to-End TLS/SSL erforderlich ist.

Wenn Sie vor API Management einen Reverseproxy haben (der selbst auch als Reverseproxy fungiert), können Sie eine benutzerdefinierte Domäne in Ihrer API-Verwaltungsinstanz konfigurieren, um die Verwendung des azure-api.net Hostnamens zu vermeiden. Sie können ein vorhandenes oder kostenloses verwaltetes Zertifikat importieren, wenn End-to-End TLS/SSL erforderlich ist. Wie bereits erwähnt, sind APIs jedoch weniger sensibel für die Probleme, die durch Übereinstimmungen mit Hostnamen verursacht werden, sodass diese Konfiguration möglicherweise nicht so wichtig ist.

Wenn Sie Ihre Anwendungen auf anderen Plattformen hosten, z. B. auf Kubernetes oder direkt auf virtuellen Computern, gibt es keine integrierte Funktionalität, die vom namen des eingehenden Hostnamens abhängt. Sie sind dafür verantwortlich, wie der Hostname auf dem Anwendungsserver selbst verwendet wird. Die Empfehlung, den Hostnamen beizubehalten, gilt in der Regel immer noch für alle Komponenten in Ihrer Anwendung, die davon abhängig sind, es sei denn, Sie machen Ihre Anwendung speziell auf Reverseproxys aufmerksam, und achten Sie beispielsweise auf die forwarded oder X-Forwarded-Host Header.

Reverseproxykonfiguration

Wenn Sie die Back-Ends innerhalb des Reverseproxys definieren, können Sie weiterhin die Standarddomäne des Back-End-Diensts verwenden, z. B. https://contoso.azurewebsites.net/. Diese URL wird vom Reverseproxy verwendet, um die richtige IP-Adresse für den Back-End-Dienst aufzulösen. Wenn Sie die Standarddomäne der Plattform verwenden, ist die IP-Adresse immer korrekt. Normalerweise können Sie die öffentlich zugängliche Domäne wie contoso.comnicht verwenden, da sie in die IP-Adresse des Reverseproxys aufgelöst werden soll. (Es sei denn, Sie verwenden erweiterte DNS-Auflösungstechniken wie Split-Horizon-DNS-).

Mit den meisten Reverseproxys können Sie konfigurieren, welcher Hostname an den Back-End-Dienst übergeben wird. In den folgenden Informationen wird erläutert, wie Sie für die am häufigsten verwendeten Azure-Dienste sicherstellen, dass der ursprüngliche Hostname der eingehenden Anforderung verwendet wird.

Anwendungsgateway

Wenn Sie Anwendungsgateway als Reverseproxy verwenden, können Sie sicherstellen, dass der ursprüngliche Hostname beibehalten wird, indem Sie Außerkraftsetzung mit neuem Hostnamen in der Back-End-HTTP-Einstellung deaktivieren. Dadurch werden sowohl Hostname von back-End-Adresse auswählen als auch Außerkraftsetzung mit einem bestimmten Domänennamendeaktiviert. (Beide Einstellungen setzen den Hostnamen außer Kraft.) In den Azure Resource Manager-Eigenschaften für das Anwendungsgateway-entspricht diese Konfiguration dem Festlegen der hostName Eigenschaft auf null und pickHostNameFromBackendAddress auf false.

Da Integritätssonden außerhalb des Kontexts einer eingehenden Anforderung gesendet werden, können sie den richtigen Hostnamen nicht dynamisch bestimmen. Stattdessen müssen Sie einen benutzerdefinierten Integritätstest erstellen, Hostname aus back-End-HTTP-Einstellungenauswählen deaktivieren und explizit den Hostnamenangeben. Für diesen Hostnamen sollten Sie auch eine entsprechende benutzerdefinierte Domäne verwenden, um Konsistenz zu gewährleisten. (Sie könnten jedoch die Standarddomäne der Hostingplattform hier verwenden, da Integritätssonden falsche Cookies ignorieren oder URLs in der Antwort umleiten.)

Azure Front Door

Wenn Sie Azure Front Doorverwenden, können Sie den Hostnamen beibehalten, indem Sie den Ursprungshostheader in der Ursprungsdefinition leer lassen. In der Ressourcen-Manager-Definition des Ursprungsentspricht diese Konfiguration dem Festlegen originHostHeader auf null.

API-Verwaltung

Standardmäßig überschreibt API-Verwaltung den Hostnamen, der an das Back-End gesendet wird, mit der Hostkomponente der Webdienst-URL der API (die dem serviceUrl Wert der Ressourcen-Manager-Definition der API-entspricht).

Sie können die API-Verwaltung erzwingen, stattdessen den Hostnamen der eingehenden Anforderung zu verwenden, indem Sie wie folgt einen inboundSet-Header Richtlinie hinzufügen:

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

Wie bereits erwähnt, sind APIs jedoch weniger sensibel für die Probleme, die durch Übereinstimmungen mit Hostnamen verursacht werden, sodass diese Konfiguration möglicherweise nicht so wichtig ist.

Nächste Schritte

• App Service-
• Spring Apps
• Anwendungsgateway-
• Azure Front Door
• API-Verwaltung

Verwandte Ressourcen

• Zero-Trust-Netzwerk für Webanwendungen mit Azure Firewall and Application Gateway
• Schützen von APIs mit anwendungsgateway und API-Verwaltung
• Unternehmensbereitstellung mit App Services Environment