Nginx 1.30-Änderungen in Apigee Edge 4.54.00

Überblick über die Nginx-Änderungen

Apigee Edge for Private Cloud 4.54.00 enthält ein obligatorisches Upgrade auf Nginx Version 1.30 auf Edge-Routern.

Mit der Veröffentlichung von Nginx 1.26 wurden mehrere wichtige Änderungen eingeführt, um die Sicherheit zu verbessern und die Einhaltung der HTTP-Standards zu gewährleisten. Die wichtigsten Updates sind:

Umgang mit Leerzeichen in Headernamen und ‑werten

Zur Verbesserung der Sicherheit wurde die Einhaltung von RFC 7230 verstärkt, insbesondere im Hinblick auf den Umgang mit Leerzeichen in Headern. Weitere Informationen zu diesen Änderungen finden Sie im Anhang.

Umgang mit den Headern Content-Length und Transfer-Encoding

Eine der gängigen Techniken bei Request-Smuggling-Angriffen besteht darin, HTTP-Anfragen mit den Headern Content-Length und Transfer-Encoding zu senden. Apigee Edge war bereits gegen solche Angriffe geschützt, aber Nginx blockiert jetzt explizit Anfragen, die beide Header enthalten. Wenn eine solche Anfrage gesendet wird, antwortet Nginx mit dem Fehler 400 Bad Request.

Unterstützte Verschlüsselungen

Die Liste der unterstützten Verschlüsselungen für Northbound-Anfragen kann sich mit dieser Version ändern. Sie können die von OpenSSL auf Ihrem Routerhost unterstützten Verschlüsselungen prüfen, um die aktualisierte Liste der verfügbaren Verschlüsselungen zu erhalten.

Unterstützte Schlüsselgrößen

Bisher wurden RSA-, DSA- und DH-Schlüssel mit weniger als 2048 Bit und ECC-Schlüssel mit weniger als 224 Bit standardmäßig akzeptiert. Mit diesem Update sind solche Schlüssel jedoch nicht mehr für unidirektionale und bidirektionale TLS-Verbindungen für Northbound-Anfragen zulässig.

Anhang

Leerzeichen in Headern

Es gibt drei Hauptänderungen:

  1. Bestimmte Headernamen, die zuvor zulässig waren, sind jetzt in Nginx 1.26 nicht mehr zulässig. Anfragen mit diesen Headern führen zu einem 400 Bad Request-Fehler.
  2. Bestimmte Headerwerte, die zuvor zulässig waren, sind jetzt in Nginx 1.26 nicht mehr zulässig. Anfragen mit diesen Headern führen ebenfalls zu einem 400 Bad Request-Fehler.
  3. Einige Header, die zuvor von Nginx akzeptiert wurden, aber Fehler nachgelagert im Message Processor verursacht haben, werden jetzt direkt von Nginx abgelehnt. Obwohl diese Header weiterhin zu API-Fehlern führen, ändern sich die HTTP-Fehlermeldungen.

Im folgenden Abschnitt finden Sie Beispiele für verschiedene Headernamen und ‑werte, die nicht zulässig sind. Dies sind nur Beispiele und die Liste ist möglicherweise nicht vollständig. Es wird empfohlen, die Richtlinien von RFC 7230 für Header einzuhalten.

Änderungen bei Headernamen

In diesem Abschnitt sind verschiedene Headernamen aufgeführt, die in Nginx 1.20.1 zulässig waren, aber in Nginx 1.26 nicht mehr zulässig sind.

Szenario Beispiele für Headernamen
Steuerzeichen am Anfang, Ende oder zwischen dem Headernamen { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
Führende und nachgestellte Leerzeichen im Headernamen {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
Führende und nachgestellte HTAB im Headernamen {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
Führende und nachgestellte Kombination aus HTAB und WS im Headernamen {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
Zeilenumbruch (\n) zwischen Headernamen, gefolgt von WS oder einer Reihe von WS {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
Zeilenumbruch (\n) zwischen Headernamen, gefolgt von HTAB oder einer Reihe von HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
Wagenrücklauf (\r) und Zeilenumbruch (\n) zwischen Headernamen, gefolgt von HTAB oder einer Reihe von HTAB {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Wagenrücklauf (\r) und Zeilenumbruch (\n) zwischen Headernamen, gefolgt von WS oder einer Reihe von WS {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

Änderungen bei Headerwerten

In diesem Abschnitt sind verschiedene Headerwerte aufgeführt, die in Nginx 1.20.1 zulässig waren, aber in Nginx 1.26 nicht mehr zulässig sind.

Szenario Beispiele
\r\n oder eine Kombination aus \r\n mit WS oder HTAB zwischen HEADERVALUE zulässig {"Header47", "Value47\r\n MultiLine"},
{"Header48", "Value48\r\n MultiLine"},
{"Header49b", "Value49b\r\n \r\nMultiLine"},
{"Header50", "Value50 \r\n MultiLine"},
{"Header51", "Value51\r\n\tMultiLine"},
{"Header52", "Value52\r\n\t\tMultiLine"},
{"Header53", "Value53\t\r\n\tMultiLine"}
\n oder eine Kombination aus \n mit WS oder HTAB zwischen HEADERVALUE zulässig {"Header61", "Value\n 61Multiline"},
{"Header62", "Value\n 63Multiline"},
{"Header65", "Value\n\t65"},
{"Header66", "Value\n\t\t66"},
{"Header67", "Value\n 67"},
{"Header68", "Value\n 68"}

Änderung der HTTP-Fehlerantwort

In diesem Abschnitt werden Header behandelt, die vom alten Nginx zugelassen, aber vom Upstream-Message Processor abgelehnt wurden, was zu einem Statuscode 400 führte. In Nginx 1.26 verursachen solche Header jedoch Fehler direkt in Nginx, wodurch verhindert wird, dass die Anfrage an den Message Processor weitergeleitet wird.

Für Clients, die solche Header senden, bleibt der HTTP-Statuscode 400. Der HTTP-Antworttext kann sich jedoch ändern, da der Fehler jetzt von Nginx und nicht vom Message Processor generiert wird.

Szenario Beispiele
HTAB oder WS zwischen HEADERNAME

Der Message Processor lehnt solche Anfragen ab. Mit Nginx 1.26 werden diese Anfragen von Nginx selbst abgelehnt. Der API-Nutzer erhält eine 400-Fehlerantwort mit einer Nginx-Fehlermeldung im Text.

 {"Header 5", "Value5"},
{"Header\t14", "Value14"},
{"Header\t 32", "Value32"},
{"Header \t33", "Value33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Value40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}