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. Wird auf dem Reverseproxy ein anderer Hostname verwendet als der, der gegenüber dem Back-End-Anwendungsserver angegeben wird, kann das dazu führen, dass Cookies oder Umleitungs-URLs nicht ordnungsgemäß funktionieren. Beispielsweise kann der Sitzungszustand verloren gehen, es können Authentifizierungsfehler auftreten, 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, sodass der Anwendungsserver die gleiche Domäne wie der Webbrowser sieht.

Dieser Leitfaden betrifft insbesondere Anwendungen, die in PaaS-Angeboten (Platform-as-a-Service) wie Azure App Service und Azure Spring Apps gehostet werden. Dieser Artikel enthält spezifische Implementierungsleitfäden für Azure Application Gateway, Azure Front Door und Azure API Management, die häufig als Reverseproxydienste verwendet werden.

Wenn Sie End-to-End-TLS/SSL benötigen (die Verbindung zwischen dem Reverseproxy und dem Back-End-Dienst verwendet HTTPS), benötigt der Back-End-Dienst außerdem ein entsprechendes TLS-Zertifikat für den ursprünglichen Hostnamen. Diese Anforderung erhöht die Komplexität im Betrieb beim Bereitstellen und Erneuern von Zertifikaten, aber viele PaaS-Dienste bieten kostenlose, vollständig verwaltete TLS-Zertifikate.

Kontext

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 verwendet wurde, um darauf zuzugreifen. Dies ist der Host der Anforderung. Dabei kann es sich um eine IP-Adresse handeln, aber in der Regel ist es ein Name wie contoso.com (der dann vom Browser mithilfe von DNS in eine IP-Adresse aufgelöst wird). Der Hostwert wird in der Regel von der Hostkomponente des Anforderungs-URI bestimmt, den der Browser als HostHTTP-Header an die Anwendung sendet.

In einigen Szenarien, insbesondere wenn ein HTTP-Reverseproxy in der Anforderungskette vorhanden ist, kann der ursprüngliche Hostheader geändert werden, bevor er den Anwendungsserver erreicht. Ein Reverseproxy schließt die Clientnetzwerksitzung und richtet eine neue Verbindung mit dem Back-End ein. In dieser neuen Sitzung kann entweder der ursprüngliche Hostname der Clientsitzung übernommen oder ein neuer festgelegt werden. Im letzteren Fall sendet der Proxy oftmals noch den ursprünglichen Hostwert in anderen HTTP-Headern wie Forwarded oder X-Forwarded-Host. Mit diesem Wert können Anwendungen den ursprünglichen Hostnamen bestimmen, jedoch nur, wenn sie zum Lesen dieser Header programmiert sind.

Gründe für die Verwendung des Hostnamens durch Webplattformen

Mehrinstanzenfähige PaaS-Dienste erfordern häufig einen registrierten und überprüften Hostnamen, um eine eingehende Anforderung an den Back-End-Server des entsprechenden Mandanten weiterzuleiten. Dies liegt daran, dass es in der Regel einen gemeinsamen Pool von Load Balancern gibt, die eingehende Anforderungen für alle Mandanten akzeptieren. Die Mandanten verwenden in der Regel den Namen des Eingangshosts, um das richtige Back-End für den Kundenmandanten zu suchen.

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

Sie verwenden diese Standarddomänen nicht für Produktionsbereitstellungen. Vielmehr stellen Sie Ihre eigene Domäne bereit, die sich an der Marke Ihres Unternehmens oder Ihrer Anwendung orientiert. Beispielsweise könnte contoso.com im Hintergrund in die Web-App contoso.azurewebsites.net auf App Service aufgelöst werden, aber diese Domäne sollte für einen Endbenutzer, der die Website besucht, nicht sichtbar sein. 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.

Gründe für die Verwendung des Hostnamens durch Anwendungen

Zwei häufige Gründe, warum ein Anwendungsserver den Hostnamen benötigt, sind das Erstellen absoluter URLs und das Ausstellen von Cookies für eine bestimmte Domäne. Etwa in Fällen, wenn der Anwendungscode Folgendes leisten muss:

• Rückgabe einer absoluten anstelle einer relativen URL in seiner HTTP-Antwort (obwohl Websites im Allgemeinen nach Möglichkeit relative Links rendern).
• Generieren einer URL, die außerhalb der HTTP-Antwort verwendet werden soll, wenn keine relativen URLs verwendet werden können, etwa beim Senden eines Links zur Website an einen Benutzer per E-Mail.
• Generieren einer absoluten Umleitungs-URL für einen externen Dienst. Beispielsweise für einen Authentifizierungsdienst wie Microsoft Entra ID, um anzugeben, wohin der Benutzer nach erfolgreicher Authentifizierung zurückgeleitet werden soll.
• Ausstellen von HTTP-Cookies, die auf einen bestimmten Host beschränkt sind, wie im Domain-Attribut des Cookies definiert.

Sie können alle diese Anforderungen erfüllen, indem Sie der Konfiguration der Anwendung den erwarteten Hostnamen hinzufügen und diesen statisch definierten Wert anstelle des Namens des Eingangshosts in der 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 eigene eindeutige Hostnamen aufweisen (wie tenant1.contoso.com und tenant2.contoso.com).

Manchmal wird der Name des Eingangshosts von Komponenten außerhalb des Anwendungscodes oder in Middleware auf dem Anwendungsserver verwendet, über die Sie nicht die vollständige Kontrolle haben. Im Folgenden finden Sie einige Beispiele:

• In App Service können Sie für Ihre Web-App HTTPS erzwingen. Dies führt dazu, dass HTTP-Anforderungen, die nicht sicher sind, zu HTTPS umgeleitet werden. In diesem Fall wird der Name des Eingangshosts 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 Eingangshost zum Generieren der HTTPS-URL verwendet.
• App Service verfügt über eine ARR-Affinitätseinstellung, die beständige Sitzungen ermöglicht, sodass Anforderungen von derselben Browserinstanz immer vom gleichen Back-End-Server bedient werden. Dies wird durch die App Service Front-Ends ausgeführt, die der HTTP-Antwort ein Cookie hinzufügen. Die Domain des Cookies wird auf den Eingangshost festgelegt.
• App Service bietet Authentifizierungs- und Autorisierungsfunktionen, mit denen Benutzer sich problemlos bei APIs anmelden und auf Daten zugreifen können.
  • Der Name des Eingangshosts wird verwendet, um die Umleitungs-URL zu erstellen, an die der Identitätsanbieter den Benutzer nach erfolgreicher Authentifizierung zurückgeben muss.
  • Wenn Sie dieses Feature standardmäßig aktivieren, wird außerdem die HTTP-zu-HTTPS-Umleitung aktiviert. Auch hier wird der Name des Eingangshosts verwendet, um den Umleitungsspeicherort zu generieren.

Warum Sie versucht sein könnten, den Hostnamen zu überschreiben

Angenommen, Sie erstellen eine Webanwendung in App Service, die die Standarddomäne contoso.azurewebsites.net aufweist. (Oder in einem anderen Dienst wie Azure Spring Apps.) Sie haben keine benutzerdefinierte Domäne in App Service konfiguriert. Wenn Sie vor dieser Anwendung einen Reverseproxy wie Application Gateway (oder einen ähnlichen Dienst) implementieren möchten, legen Sie den DNS-Eintrag für contoso.com so fest, dass er zur IP-Adresse von Application Gateway aufgelöst wird. Daher empfängt er die Anforderung für contoso.com vom Browser und ist dafür konfiguriert, diese Anforderung an die IP-Adresse weiterzuleiten, zu der contoso.azurewebsites.net aufgelöst wird: Dies ist der endgültige Back-End-Dienst für den angeforderten Host. In diesem Fall erkennt App Service die benutzerdefinierte Domäne contoso.com jedoch nicht und lehnt alle eingehenden Anforderungen für diesen Hostnamen ab. Er kann nicht bestimmen, wohin die Anforderung weitergeleitet werden soll.

Es sieht vielleicht so aus, dass die einfache Möglichkeit, diese Konfiguration zum Funktionieren zu bringen, darin besteht, den Host-Header der HTTP-Anforderung in Application Gateway außer Kraft zu setzen oder umzuschreiben und ihn auf den Wert contoso.azurewebsites.net festzulegen. Wenn Sie dies tun, sieht die ausgehende Anforderung von Application Gateway so aus, als wäre die ursprüngliche Anforderung tatsächlich für contoso.azurewebsites.net anstelle von contoso.com bestimmt:

An diesem Punkt erkennt App Service den Hostnamen und akzeptiert die Anforderung, ohne dass ein benutzerdefinierter Domänenname konfiguriert werden muss. Tatsächlich erleichtert Application Gateway das Überschreiben des Hostheaders mit dem Host des Back-End-Pools. Azure Front Door verhält sich sogar standardmäßig so.

Die Schwierigkeit bei dieser Lösung besteht jedoch darin, dass es zu verschiedenen Problemen führen kann, wenn der ursprüngliche Hostname für die App nicht sichtbar ist.

Mögliche Probleme

Falsche absolute URLs

Wenn der ursprüngliche Hostname nicht beibehalten wird und der Anwendungsserver den Namen des Eingangshosts zum Generieren absoluter URLs verwendet, wird möglicherweise die Back-End-Domäne gegenüber Endbenutzern offengelegt. Diese absoluten URLs können vom Anwendungscode oder, wie bereits erwähnt, von Plattformfeatures wie der Unterstützung der HTTP-zu-HTTPS-Umleitung in App Service und Azure Spring Apps generiert werden. In diesem Diagramm ist das Problem dargestellt:

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

Dies kann sogar ein Sicherheitsrisiko darstellen, in dem häufigen Fall, dass der Reverseproxy auch als Web Application Firewall fungiert. Der Benutzer erhält eine URL, die direkt zur Back-End-Anwendung führt 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 Security Assertion Markup Language (SAML) 2.0 verwenden. Diese Umleitungs-URLs können vom Anwendungsserver oder der Middleware selbst oder, wie bereits erwähnt, durch Plattformfeatures wie die App Service Authentifizierungs- und Autorisierungsfunktionen generiert werden. In diesem Diagramm ist das Problem dargestellt:

1. Der Browser sendet eine Anforderung für contoso.com an den Reverseproxy.
2. Der Reverseproxy schreibt den Hostnamen in der Anforderung an die Back-End-Webanwendung (oder an eine ähnliche Standarddomäne für einen anderen Dienst) in contoso.azurewebsites.net um.
3. Die Anwendung generiert eine absolute Umleitungs-URL, die auf dem eingehenden Hostnamen contoso.azurewebsites.net basiert, z. B. https://contoso.azurewebsites.net/.
4. Der Browser wendet sich an den Identitätsanbieter, um den Benutzer zu authentifizieren. Die Anforderung enthält die generierte Umleitungs-URL, um anzugeben, wohin der Benutzer nach erfolgreicher Authentifizierung zurückgeleitet werden soll.
5. Für Identitätsanbieter ist es in der Regel erforderlich, dass Umleitungs-URLs im Voraus registriert werden. Daher sollte der Identitätsanbieter die Anforderung an diesem Punkt ablehnen, da die angegebene Umleitungs-URL nicht registriert ist. (Sie sollte nicht verwendet werden.) Wenn die Umleitungs-URL jedoch aus irgendeinem Grund registriert wird, leitet der Identitätsanbieter den Browser auf die Umleitungs-URL um, die in der Authentifizierungsanforderung angegeben wurde. In diesem Fall lautet die URL: https://contoso.azurewebsites.net/.
6. Der Browser folgt dieser URL, die direkt zum Back-End-Dienst statt zurück zum Reverseproxy führt.

Fehlerhafte Cookies

Eine Nichtübereinstimmung des Hostnamens kann außerdem zu Problemen führen, wenn der Anwendungsserver Cookies ausgibt und den Namen des Eingangshosts verwendet, um das Domain-Attribut des Cookies zu erstellen. Das Domänenattribut 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 die App Service ARR-Affinitätseinstellung generiert werden. In diesem Diagramm ist das Problem dargestellt:

1. Der Browser sendet eine Anforderung für contoso.com an den Reverseproxy.
2. Der Reverseproxy schreibt den Hostnamen in der Anforderung an die Back-End-Webanwendung (oder an eine ähnliche Standarddomäne für einen anderen Dienst) in contoso.azurewebsites.net um.
3. Die Anwendung generiert ein Cookie, das eine Domäne basierend auf dem eingehenden Hostnamen contoso.azurewebsites.net verwendet. Der Browser speichert das Cookie für diese bestimmte Domäne anstelle der contoso.com-Domäne, die der Benutzer tatsächlich verwendet.
4. Der Browser schließt das Cookie in keine nachfolgende Anforderung für contoso.com ein, da die Domäne contoso.azurewebsites.net des Cookies nicht mit der Domäne der Anforderung übereinstimmt. Die Anwendung empfängt das Cookie nicht, das sie zuvor ausgegeben hatte. Das hat zur Folge, dass der Benutzer seinen Zustand verlieren kann, der im Cookie enthalten sein soll, oder dass Features wie ARR-Affinität nicht funktionieren. Leider generiert keins dieser Probleme einen Fehler oder ist für den Endbenutzer direkt sichtbar. Dies erschwert die Problembehandlung.

Implementierungsleitfaden für allgemeine Azure-Dienste

Zur Vermeidung der hier beschriebenen potenziellen Probleme empfiehlt es sich, im Aufruf zwischen dem Reverseproxy und dem Back-End-Anwendungsserver den ursprünglichen Hostnamen beizubehalten:

Back-End-Konfiguration

Für viele Webhostingplattformen ist es erforderlich, dass Sie die zulässigen Namen von Eingangshosts explizit konfigurieren. In den folgenden Abschnitten wird beschrieben, wie diese Konfiguration für die gängigsten Azure-Dienste implementiert wird. 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 die Verwendung des Standardhostnamens azurewebsites.net gegenüber dem Back-End vermeiden. 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 mithilfe eines TXT-Eintrags überprüfen, ohne Auswirkungen auf Ihre regulären CNAME oder A-Einträge. (Diese Datensätze werden weiterhin auf die IP-Adresse des Reverseproxys aufgelöst.) Wenn Sie End-to-End-TLS/SSL benötigen, können Sie ein vorhandenes Zertifikat aus dem Key Vault importieren oder ein App Service Certificate für Ihre benutzerdefinierte Domäne verwenden. (Beachten Sie, dass das kostenlose App Service verwaltetes Zertifikat in diesem Fall nicht verwendet werden kann, da der DNS-Eintrag der Domäne erforderlich ist, um direkt auf App Service aufzulösen, nicht auf den Reverseproxy.)

Wenn Sie Spring Apps verwenden, können Sie analog dazu 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 Sie End-to-End-TLS/SSL benötigen.

Wenn Sie über einen Reverseproxy verfügen, der API Management (das seinerseits auch als Reverseproxy fungiert) vorgelagert ist, können Sie eine benutzerdefinierte Domäne auf Ihrer API Management Instanz konfigurieren, um die Verwendung des azure-api.net-Hostnamens zu vermeiden. Sie können ein vorhandenes oder kostenloses verwaltetes Zertifikat importieren, wenn Sie End-to-End-TLS/SSL benötigen. Wie bereits erwähnt, reagieren APIs jedoch weniger empfindlich auf die Probleme, die durch Nichtübereinstimmung des Hostnamens 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 Eingangshosts abhängt. Wie der Hostname auf dem Anwendungsserver selbst verwendet wird, fällt in Ihre Zuständigkeit. Die Empfehlung, den Hostnamen beizubehalten, gilt in der Regel weiterhin für alle Komponenten in Ihrer Anwendung, die davon abhängen, es sei denn, Sie implementieren in Ihrer Anwendung eine Reaktion auf Reverseproxys und beispielsweise die Beachtung der Header forwarded oder X-Forwarded-Host.

Reverseproxykonfiguration

Wenn Sie die Back-Ends innerhalb des Reverseproxys definieren, können Sie trotzdem 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 immer garantiert, dass die IP-Adresse richtig ist. In der Regel können Sie die öffentlich zugängliche Domäne wie contoso.com nicht verwenden, da sie zur IP-Adresse des Reverseproxys selbst aufgelöst werden sollte. (Es sei denn, Sie verwenden erweiterte Techniken zur DNS-Auflösung, z. B Split-Horizon-DNS).

Bei 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 gängigsten Azure-Dienste sicherstellen, dass der ursprüngliche Hostname der eingehenden Anforderung verwendet wird.

Application Gateway

Wenn Sie Application Gateway als Reverseproxy verwenden, können Sie sicherstellen, dass der ursprüngliche Hostname beibehalten wird, indem Sie Mit neuem Hostnamen überschreiben in der HTTP-Einstellung auf dem Back-End deaktivieren. Dadurch werden sowohl Hostnamen aus Back-End-Adresse auswählen als auch Mit bestimmtem Domänennamen überschreiben deaktiviert. (Beide Einstellungen überschreiben den Hostnamen.) In den Azure Resource Manager-Eigenschaften für Application Gateway entspricht diese Konfiguration dem Festlegen der hostName-Eigenschaft auf null und pickHostNameFromBackendAddress auf false.

Da Integritätstest 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, Hostnamen aus Back-End-HTTP-Einstellungen auswählen deaktivieren und den Hostnamen explizit angeben. Für diesen Hostnamen sollten Sie aus Konsistenzgründen außerdem eine geeignete benutzerdefinierte Domäne verwenden. (Sie können hier jedoch die Standarddomäne der Hostingplattform verwenden, da Integritätstest falsche Cookies oder Umleitungs-URLs in der Antwort ignorieren.)

Azure Front Door

Wenn Sie Azure Front Door verwenden, können Sie das Überschreiben des Hostnamens vermeiden, indem Sie den Back-End-Hostheader in der Definition des Back-End-Pools leer lassen. In der Resource Manager Definition des Back-End-Pools entspricht diese Konfiguration der Festlegung von backendHostHeader auf null.

Wenn Sie Azure Front Door Standard oder Premium verwenden, können Sie den Hostnamen beibehalten, indem Sie den Header des Ursprungshosts in der Ursprungsdefinition leer lassen. In der Resource Manager-Definition des Ursprungs entspricht diese Konfiguration der Festlegung von originHostHeader auf null.

API Management

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

Sie können erzwingen, dass API Management stattdessen den Hostnamen der eingehenden Anforderung verwenden, indem Sie wie folgt eine Richtlinie inbound HTTP-Header festlegen hinzufügen:

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

Wie bereits erwähnt, reagieren APIs jedoch weniger empfindlich auf die Probleme, die durch Nichtübereinstimmung des Hostnamens verursacht werden, sodass diese Konfiguration möglicherweise nicht so wichtig ist.

Nächste Schritte

• App Service
• Spring Apps
• Application Gateway
• Azure Front Door
• API Management

Zugehörige Ressourcen

• Zero Trust-Netzwerk für Webanwendungen mit Azure Firewall und Application Gateway
• Schützen von APIs mit Application Gateway und API Management
• Bereitstellung einer Unternehmens-App per App Service-Umgebung