Umschreiben von HTTP-Headern und einer URL mithilfe von Application Gateway

Mit dem Anwendungsgateway können Sie ausgewählte Inhalte in Anforderungen und Antworten neu schreiben. Mit diesem Feature können Sie URLs, Abfragezeichenfolgenparameter übersetzen und Anforderungs- und Antwortheader ändern. Sie können auch Bedingungen hinzufügen, um sicherzustellen, dass die URL oder die angegebenen Header nur neu geschrieben werden, wenn bestimmte Bedingungen erfüllt sind. Diese Bedingungen basieren auf den Anforderungs- und Antwortinformationen.

Die Features zum Umschreiben von HTTP-Headern und URLs sind nur für die Application Gateway v2-SKU verfügbar.

Anforderungs- und Antwortheader

Application Gateway ermöglicht Ihnen das Hinzufügen, Entfernen oder Aktualisieren von HTTP-Anforderungs- und -Antwortheadern, während die Anforderungs-/Antwortpakete zwischen dem Client und den Back-End-Pools verschoben werden. HTTP-Header ermöglichen es einem Client und einem Server, zusätzliche Informationen mit einer Anforderung oder Antwort zu übergeben. Durch das Umschreiben dieser Kopfzeilen können Sie wichtige Aufgaben ausführen, darunter:

• Hinzufügen sicherheitsbezogener Kopfzeilenfelder wie HSTS und X-XSS-Protection
• Entfernen von Antwortheaderfeldern, die vertrauliche Informationen möglicherweise offenlegen
• Entfernen von Portinformationen aus X-Forwarded-For-Headern

Sie können alle Kopfzeilen in Anforderungen und Antworten neu schreiben, mit Ausnahme der Connection und Upgrade Kopfzeilen. Sie können auch über das Anwendungsgateway benutzerdefinierte Header erstellen und sie den Anforderungen und Antworten hinzufügen, die über das Gateway weitergeleitet werden. Informationen zum Umschreiben von Anforderungs- und Antwortheadern mit Dem Anwendungsgateway mithilfe des Azure-Portals finden Sie hier.

URL-Pfad und Abfragezeichenfolge

Mit der Funktion zum Umschreiben einer URL in Application Gateway können Sie folgende Aktionen ausführen:

• Schreiben Sie den Hostnamen, pfad und die Abfragezeichenfolge der Anforderungs-URL neu.

• Wählen Sie aus, ob Sie die URLs aller Anforderungen eines Listeners oder nur die Anforderungen umschreiben möchten, die einer oder mehreren festgelegten Bedingungen entsprechen. Diese Bedingungen basieren auf den Anforderungseigenschaften (Anforderungsheader und Servervariablen).

• Weiterleiten der Anforderung (Auswählen des Back-End-Pools) basierend auf der ursprünglichen URL oder der neu generierten URL

Informationen zum Umschreiben der URL mit dem Anwendungsgateway mithilfe des Azure-Portals finden Sie hier.

Grundlegendes zu Neuschreibungen im Anwendungsgateway

Ein Umschreibsatz ist eine Sammlung einer Routingregel, einer Bedingung und einer Aktion.

• Zuordnung der Anforderungsroutingregel: Die Umschreibungskonfiguration wird mit einem Quelllistener durch dessen Routingregel verknüpft. Wenn Sie eine Routingregel des Typs "Basic" verwenden, wird die Rewrite-Konfiguration dem Listener zugeordnet und als globales Neuschreiben verwendet. Wenn Sie eine pfadbasierte Routingregel verwenden, definieren Sie die Umschreibungskonfiguration gemäß der URL-Pfadzuordnung. Im letzteren Fall gilt sie nur für einen bestimmten Pfadbereich einer Site. Sie können einen Umschreibsatz auf mehrere Routingregeln anwenden, aber eine Routingregel kann nur eine Neuschreibung zugeordnet haben.

• Bedingung neu schreiben: Diese Konfiguration ist optional. Basierend auf den von Ihnen definierten Bedingungen wertet das Anwendungsgateway den Inhalt der HTTP(S)-Anforderungen und -Antworten aus. Die nachfolgende "Rewrite-Aktion" tritt auf, wenn die HTTP(S)-Anforderung oder -Antwort mit dieser Bedingung übereinstimmt. Wenn Sie der Aktion mehr als eine Bedingung zuordnen, erfolgt die Aktion nur, wenn alle Bedingungen erfüllt sind. Mit anderen Worten, es ist eine logische AND-Operation. Sie können Umschreibungsbedingungen verwenden, um den Inhalt von HTTP(S)-Anforderungen und -Antworten auszuwerten. Mit dieser optionalen Konfiguration können Sie eine Umschreibung nur dann durchführen, wenn mindestens eine Bedingung erfüllt ist. Das Anwendungsgateway wertet mit diesen Typen von Variablen den Inhalt von Anforderungen und Antworten aus:

  Sie können die folgenden Typen auswählen, um nach einer Bedingung zu suchen:

  • HTTP-Header (Anforderung und Antwort)
  • Unterstützte Servervariablen

  Mit einer Bedingung können Sie auswerten, ob eine angegebene Kopfzeile oder Variable vorhanden ist, indem Sie ihre Werte über Text oder ein Regex-Muster abgleichen. Bei erweiterten Konfigurationen für das Umschreiben können Sie auch den Wert der Header- oder Servervariable für die spätere Verwendung unter „Umschreibungsaktion“ erfassen. Erfahren Sie mehr über Muster und Aufzeichnungen.

• Aktion neu schreiben: Mit dem Rewrite-Aktionssatz können Sie Header (Anforderung oder Antwort) oder die URL-Komponenten neu schreiben.

  Eine Aktion kann die folgenden Werttypen oder deren Kombinationen aufweisen:

  • Text.
  • Wert des Anforderungsheaders, um den Wert eines erfassten Anforderungsheaders zu verwenden, geben Sie die Syntax als {http_req_headerName} an.
  • Wert der Antwortkopfzeile – Um den Wert einer erfassten Antwortkopfzeile aus der vorherigen Bedingung zu verwenden, geben Sie dies mithilfe der Syntax {http_resp_headerName} an. Der Rewrite-Aktionsblock unterstützt auch das Feld „Header Value Matcher“ für den Set-Cookie-Header. Mit diesem optionalen Feld können Sie den Wert einer bestimmten Kopfzeile abgleichen und erfassen, wenn mehrere Set-Cookie Kopfzeilen mit demselben Namen vorhanden sind. Um den erfassten Wert dieses bestimmten Cookies zu bearbeiten, können Sie dann {capt_header_value_matcher} verwenden. Weitere Informationen zur Erfassung finden Sie unter "Aktionssatz".
  • Servervariable – Um eine Servervariable zu verwenden, geben Sie die Syntax als {var_serverVariable} an. Liste mit den unterstützten Servervariablen.

Wenn Sie eine Aktion zum Umschreiben einer URL verwenden, werden die folgenden Vorgänge unterstützt:

• URL-Pfad: Der neue Wert, der als Pfad festgelegt werden soll.
• URL-Abfragezeichenfolge: Der neue Wert, in den die Abfragezeichenfolge umgeschrieben werden muss.
• Pfadzuordnung erneut auswerten: Geben Sie an, ob die URL-Pfadzuordnung nach dem Umschreiben erneut ausgewertet werden muss. Wenn Sie diese Option nicht überprüfen, wird der ursprüngliche URL-Pfad verwendet, um mit dem Pfadmuster in der URL-Pfadzuordnung übereinzugleichen. Wenn Sie diese Option auf "true" festlegen, wird die URL-Pfadzuordnung erneut ausgewertet, um die Übereinstimmung mit dem umgeschriebenen Pfad zu überprüfen. Das Aktivieren dieses Schalters hilft beim Routing der Anforderung an einen anderen Back-End-Pool nach dem Umschreiben.

Musterabgleich und -erfassung

Das Anwendungsgateway unterstützt Musterabgleich und -erfassung unter Bedingung und Aktion. Unter "Aktion" wird der Musterabgleich und die Erfassung nur für einen bestimmten Header unterstützt.

Musterabgleich

Application Gateway verwendet reguläre Ausdrücke für den Musterabgleich. Verwenden Sie mit RE2 kompatible Ausdrücke, wenn Sie Ihre Musterabgleichssyntax schreiben.

Sie können den Musterabgleich sowohl unter „Bedingung“ als auch „Aktion“ verwenden.

• Bedingung: Verwenden Sie diese Einstellung, um die Werte für eine Header- oder Servervariable abzugleichen. Um ein Muster unter "Bedingungen" abzugleichen, verwenden Sie die Eigenschaft "pattern".
• Aktion: Musterabgleich unter Aktionssatz ist nur für den Antwortheader Set-Cookieverfügbar. Um ein Muster für Set-Cookie unter einer Aktion abzugleichen, verwenden Sie die HeaderValueMatcher Eigenschaft. Wenn der Wert erfasst wird, kann er als {capt_header_value_matcher} verwendet werden. Da mehrere Kopfzeilen vorhanden sein Set-Cookie können, können Sie mit dem Mustervergleich hier nach einem bestimmten Cookie suchen. Bei einer bestimmten Version des Benutzer-Agents möchten Sie z. B. den set-cookie Antwortheader für cookie2max-age=3600 (eine Stunde) neu schreiben. In diesem Fall verwenden Sie
  • Bedingung – Typ: Anforderungsheader, Headername: Benutzer-Agent, Muster zum Abgleichen: *2.0
  • Aktion - Umschreibetyp: Antwortheader, Aktionstyp: Setzen, Headername: Set-Cookie, Header-Wertematcher: cookie2=(.*), Headerwert: cookie2={capt_header_value_matcher_1};Max-Age=3600

Syntax für die Erfassung

Sie können Muster verwenden, um eine Teilzeichenfolge für die spätere Verwendung zu erfassen. Platzieren Sie Klammern um ein Teilmuster in der RegEx-Definition. Das erste Paar von Klammern speichert die Teilzeichenfolge im Register 1, das zweite Paar in 2 usw. Sie können beliebig viele Klammern verwenden. Perl definiert mehr nummerierte Variablen, um diese erfassten Zeichenfolgen darzustellen. Einige Beispiele finden Sie in diesem Perl-Programmierleitfaden.

• (\d)(\d) # – entspricht zwei Ziffern, die in den Gruppen 1 und 2 erfasst werden
• (\d+) # – entspricht einer oder mehrere Ziffern, die alle in Gruppe 1 erfasst werden
• (\d)+ # – entspricht einer Ziffer ein- oder mehrmals und erfasst die letzte Entsprechung in Gruppe 1

Nach der Erfassung können Sie sie im Aktionssatzwert mit dem folgenden Format verwenden:

• Bei der Erfassung eines Anforderungsheaders müssen Sie {http_req_Headername_Gruppennummer} verwenden, z. B. {http_req_User-Agent_1} oder {http_req_User-Agent_2}
• Bei der Erfassung eines Antwortheaders müssen Sie {http_resp_Headername_Gruppennummer} verwenden, Beispiel: {http_resp_Location_1} oder {http_resp_Location_2}. Wohingegen Sie für einen Antwortheader „Set-Cookie“, der über die Eigenschaft „HeaderValueMatcher“ erfasst wurde, {capt_header_value_matcher_groupNumber} verwenden müssen. Beispiel: {capt_header_value_matcher_1} oder {capt_header_value_matcher_2}.
• Für eine Servervariable müssen Sie {var_Servervariablenname_Gruppennummer} verwenden, z. B. {var_uri_path_1} oder {var_uri_path_2}

Servervariablen

Application Gateway speichert mit Servervariablen nützliche Informationen zum Server, zur Verbindung mit dem Client und zur momentanen Anforderung an die Verbindung. Beispiele für gespeicherte Informationen sind die IP-Adresse und der Webbrowsertyp des Clients. Servervariablen ändern sich dynamisch, wenn z.B. eine neue Seite geladen oder ein Formular gesendet wird. Anhand dieser Variablen können Sie Bedingungen für das erneute Generieren und Header für das erneute Generieren auswerten. Um den Wert von Servervariablen zum Umschreiben von Headern zu verwenden, müssen Sie diese Variablen in der Syntax {var_serverVariableName} angeben.

Das Application Gateway unterstützt die folgenden Servervariablen:

Variablen des Servers für gegenseitige Authentifizierung

Application Gateway unterstützt die folgenden Servervariablen für Szenarien der gegenseitigen Authentifizierung. Verwenden Sie diese Servervariablen wie andere Servervariablen.

Häufige Szenarien für die Headerumschreibungen

Entfernen von Portinformationen aus dem X-Forwarded-For-Header

Application Gateway fügt in alle Anforderungen einen X-Forwarded-For-Header ein, bevor es die Anforderungen an das Back-End weiterleitet. Dieser Header ist eine durch Trennzeichen getrennte Liste von IP-Ports. Es gibt möglicherweise Szenarien, in denen Back-End-Server in den Headern nur IP-Adressen benötigen. Sie können mit dem erneuten Generieren von Headern die Portinformationen aus dem X-Forwarded-For-Header entfernen. Dies kann beispielsweise erreicht werden, indem der Header auf die Servervariable „add_x_forwarded_for_proxy“ festgelegt wird. Alternativ können Sie auch die Variable „client_ip“ verwenden:

Ändern einer Umleitungs-URL

Das Ändern einer Umleitungs-URL kann unter bestimmten Umständen hilfreich sein. Beispielsweise können Sie Clients ursprünglich an einen Pfad wie "/Blog" umleiten, möchten sie aber aufgrund einer Änderung der Inhaltsstruktur an "/updates" senden.

Wenn der App Service eine Umleitungsantwort sendet, verwendet er den gleichen Hostnamen im Adressheader seiner Antwort wie in der Anforderung, die er vom Anwendungsgateway empfängt. Der Client sendet die Anforderung direkt an contoso.azurewebsites.net/path2 und durchläuft nicht das Anwendungsgateway (contoso.com/path2). Das Umgehen des Anwendungsgateways ist nicht wünschenswert.

Sie können dieses Problem durch Festlegen des Hostnamens im Adressheader des Anwendungsgateway-Domänennamens lösen.

Hier sind die Schritte zum Ersetzen des Hostnamens:

1. Erstellen Sie eine Umschreibregel mit einer Bedingung, die überprüft, ob der Location-Header in der Antwort azurewebsites.net enthält. Geben Sie das Muster "(https?)://ein. azurewebsites.net(.)

2. Führen Sie eine Aktion zum erneuten Generieren des Adressheaders durch, damit sie den Hostnamen des Anwendungsgateways hat. Geben Sie {http_resp_Location_1}://contoso.com{http_resp_Location_2} als Kopfzeilenwert ein. Alternativ können Sie auch die Servervariable host verwenden, um den Hostnamen entsprechend der ursprünglichen Anforderung festzulegen.

   

Implementieren von HTTP-Sicherheitsheadern, um Sicherheitsrisiken zu verhindern

Sie können verschiedene Sicherheitsrisiken beheben, indem Sie die erforderlichen Header in die Anwendungsantwort implementieren. Zu diesen Sicherheitsheadern zählen X-XSS-Protection, Strict-Transport-Security und Content-Security-Policy. Über Application Gateway können Sie diese Header für alle Antworten festlegen.

Löschen von unerwünschten Headern

Möglicherweise möchten Sie Header entfernen, die vertrauliche Informationen aus einer HTTP-Antwort anzeigen. Beispielsweise möchten Sie möglicherweise Informationen wie den Namen des Back-End-Servers, das Betriebssystem oder die Bibliothek entfernen. Sie können diese Header mit dem Anwendungsgateway entfernen:

Sie können keine Neuschreibregel erstellen, um den Hostheader zu löschen. Wenn Sie versuchen, eine Umschreibungsregel zu erstellen, bei der die Aktionsart auf „Löschen“ und der Header auf „Host“ festgelegt wird, tritt ein Fehler auf.

Überprüfen des Vorhandenseins eines Headers

Sie können einen HTTP-Anforderungs- oder -Antwortheader auf das Vorhandensein einer Header- oder Servervariablen untersuchen. Diese Untersuchung ist hilfreich, wenn Sie nur dann erneut Header generieren möchten, wenn der betreffende Header auch vorhanden ist.

Häufige Szenarien für die URL-Umschreibungen

Parameterbasierte Pfadauswahl

Verwenden Sie zum Ausführen von Szenarien, in denen Sie den Back-End-Pool basierend auf dem Wert eines Headers, eines Teils der URL oder abfragezeichenfolge in der Anforderung auswählen möchten, eine Kombination aus URL Rewrite-Funktion und pfadbasiertem Routing.

Erstellen Sie eine Neuschreibregel mit einer Bedingung, die nach einem bestimmten Parameter sucht (Abfragezeichenfolge, Header usw.), und führen Sie dann eine Aktion durch, bei der der URL-Pfad geändert wird (stellen Sie sicher, dass die Option Pfadzuordnung neu bewerten aktiviert ist). Ordnen Sie das Rewrite-Set einer Regel basierend auf einem Pfad zu. Die pfadbasierte Regel muss die gleichen URL-Pfade enthalten, die im Rewrite-Satz und dem entsprechenden Back-End-Pool angegeben sind.

Mit dem Umschreibsatz können Sie daher nach einem bestimmten Parameter suchen und ihm einen neuen Pfad zuweisen, und mit der pfadbasierten Regel können Sie diesen Pfaden Back-End-Pools zuweisen. Solange "Pfadzuordnung erneut bewerten" aktiviert ist, basieren die Verkehrsrouten auf dem im Rewrite-Set angegebenen Pfad.

Ein Anwendungsfallbeispiel mithilfe von Abfragezeichenfolgen finden Sie unter Weiterleiten von Datenverkehr mithilfe von parameterbasierter Pfadauswahl im Portal.

Umschreiben von Abfragezeichenfolgenparametern basierend auf der URL

Betrachten Sie ein Szenario einer Shoppingwebsite, bei der der benutzer sichtbare Link einfach und lesbar ist, aber der Back-End-Server benötigt die Abfragezeichenfolgenparameter, um den richtigen Inhalt anzuzeigen.

In diesem Fall kann das Anwendungsgateway Parameter aus der URL erfassen und Abfragezeichenfolgen-Schlüsselwertpaare aus diesen Parametern in der URL hinzufügen. Beispielsweise, wenn der Benutzer https://www.contoso.com/fashion/shirts in https://www.contoso.com/buy.aspx?category=fashion&product=shirts neu schreiben möchte, können Sie dies über die folgende URL-Umschreibungskonfiguration erreichen.

Bedingung : Wenn die Servervariable uri_path dem Muster entspricht /(.+)/(.+)

Aktion: Festlegen des URL-Pfads auf buy.aspx und der Abfragezeichenfolge auf category={var_uri_path_1}&product={var_uri_path_2}

Eine schrittweise Anleitung zum Erreichen des zuvor beschriebenen Szenarios finden Sie unter "Neuschreiben der URL mit Dem Anwendungsgateway mithilfe des Azure-Portals".

Häufige Probleme bei der Konfiguration der Umschreibung (Rewrite)

• Sie können "Pfadzuordnung erneut bewerten" für grundlegende Anforderungsweiterleitungsregeln nicht aktivieren. Diese Einschränkung verhindert eine endlose Auswertungsschleife für eine einfache Routingregel.

• Für pfadbasierte Routingregeln benötigen Sie mindestens eine bedingte Neuschreibregel oder eine Neuschreibregel ohne aktivierte "Pfadzuordnung neu bewerten". Diese Anforderung verhindert eine unendliche Auswertungsschleife für eine pfadbasierte Routingregel.

• Wenn eine Schleife dynamisch auf Grundlage von Clienteingaben erstellt wird, enden eingehende Anforderungen mit einem 500er-Fehlercode. Das Anwendungsgateway bedient weiterhin andere Anforderungen ohne Beeinträchtigung in diesem Szenario.

Verwenden der Umschreibung von URLs (URL-Rewrite) oder Hostheadern mit Web Application Firewall (WAF_v2 SKU)

Wenn Sie das Umschreiben von URLs oder Hostheadern konfigurieren, erfolgt die WAF-Auswertung nach der Änderung der Anforderungsheader- oder URL-Parameter, d. h. nach dem Umschreiben. Wenn Sie die URL-Umschreibungsregel oder die Hostheader-Umschreibungsregel auf Ihrem Anwendungsgateway entfernen, erfolgt die WAF-Auswertung vor der Umschreibung des Headers. Mit dieser Reihenfolge wird sichergestellt, dass die WAF-Regeln für die endgültige Anfrage gelten, die zu Ihrem Backend-Pool gelangt.

Angenommen, Sie haben die folgende Regel zum Überschreiben von Kopfzeilen – wenn der Wert der Kopfzeile "Accept" gleich "text/html" ist, dann ändern Sie den Wert zu "image/png".

Wenn nur die Header-Neuschreibung konfiguriert ist, erfolgt die WAF-Auswertung auf "Accept" : "text/html". Wenn Sie jedoch die URL-Umschreibung oder Host-Header-Umschreibung konfigurieren, erfolgt die WAF-Auswertung auf "Accept" : "image/png".

Vergleich von URL-Umschreibung und URL-Umleitung

Für eine URL-Neuschreibung schreibt das Anwendungsgateway die URL um, bevor sie die Anforderung an das Back-End sendet. Diese Aktion ändert nicht, was Benutzer im Browser sehen, da die Änderungen vom Benutzer ausgeblendet sind.

Bei einer URL-Umleitung sendet Application Gateway eine Umleitungsantwort mit der neuen URL an den Client. Für diese Antwort muss der Client seine Anforderung an die neue URL erneut senden, die in der Umleitung bereitgestellt wird. Die URL, die der Benutzer im Browser sieht, wird durch die neue URL ersetzt.

Einschränkungen

• Das erneute Generieren wird nicht unterstützt, wenn das Anwendungsgateway so konfiguriert ist, dass die Anforderungen umgeleitet werden oder eine benutzerdefinierte Fehlerseite angezeigt wird.
• Anforderungsheadernamen können alphanumerische Zeichen und Bindestriche enthalten. Kopfzeilennamen, die andere Zeichen enthalten, werden verworfen, wenn eine Anforderung an das Back-End-Ziel gesendet wird.
• Wie in RFC 7230 festgelegt, können Antwort-Headernamen beliebige alphanumerischen Zeichen und Sonderzeichen beinhalten.
• Sie können kopfzeilen nicht neu schreibenX-Original-HostConnectionupgrade.
• Neuschreibungen werden für 4xx- und 5xx-Antworten nicht unterstützt, die direkt vom Anwendungsgateway generiert werden.

Nächste Schritte

• Erfahren Sie mehr über das Umschreiben von HTTP-Headern mit Application Gateway über das Azure-Portal.
• Erfahren Sie mehr über das Umschreiben von URLs mit Application Gateway über das Azure-Portal.